There's a top-level utils/ subdir in some trees. Yes, MeP has a tool
there.
What is length used for in the rx port?
We have a local patch that uses the length to decide if/when to align
labels; it goes along with the label alignment change I made a while
back. However, the patch works best in 4.5 (align patch not
backported) and there are other optimization problems
I don't think this is suitable for the branch. Any reason why you
can't work on the trunk?
The vendor's release is 4.5 based, and 4.6 has some performance
regressions with this chip. We'd like to sync up the FSF sources with
the minor patches the vendor is using, so that their customers can
And I think the adjustments should not be done after the fact in
finish_record_layout, but rather right in place_field, where also
the fields alignment and mode are properly tracked.
It would be a lot harder to keep track of which bits are allocated and
which aren't if we do it in
In the RX chip (and others, of course), the memory-mapped peripherals
have a fixed bit-ordering independent of the endianness of data.
However, GCC defines bitfields in structures differently for different
endians - effectively always beginning allocations with the lowest
addressed byte.
To
First I have to say that people should not use bitfields to access
memory mapped peripherals. However, at least this case is not as
bad as the volatile bitfields issue.
Agreed, but that doesn't stop people from doing it, and it does lead
to more readable code.
It seems to me that the
Except that in this case we want to reverse *only* structures that
represent peripherals, *not* other structures.
I'm sorry, that just seems frigging ridiculous.
Ridiculous? Why? I see no reason why we should dictate how other
people write their software, or design their chips. Can we
I'm tempted to agree. I thought people had stopped numbering bits
in the wrong order
This has nothing to do with numbering bits, it's about how gcc
allocates bitfields within structures. Consider:
struct {
char a:4;
char b:4;
} Foo;
Nothing says that 'a' is in the LSBs of the byte, or
Tested building cc1 and xgcc for cross to mep-elf. Will commit to
trunk for 4.7 in the absence of target maintainer objections.
No objections from me.
avoid memory overrun in a test leading to potential double-free
* testsuite/test-expandargv.c (writeout_test): Fix off-by-one error:
i.e., do copy the trailing NUL byte.
Ok. Thanks!
I think we don't need filename_dirchr, only filename_dirrchr.
I see no harm in having both, for completeness, though. One could
argue they should be in separate files, but they're trivial functions
on non-dos-fs systems.
What bothers me about this patch is that we're adding yet another set
of
I was just wondering whether now would be a good time to mention
Probably not, gcc being in stage 4 and all...
Tested building cc1 and xgcc for cross to m32c-elf. Will commit to
trunk for 4.7 in the absence of target maintainer objections.
Go for it :-)
So... gcc assumes the register push/pops happen before the frame
pointer is initialized? So the epilog always restores $sp from $fp
before restoring registers?
That would make the m32c port much less efficient, since it has the
exitd opcode which restores $sp, releases the frame, and returns,
which never needs the pair of spill insns. Something to consider...
Does gcc provide a flag that says your $sp will be unspecified at the
end of this function that's valid during reload and for prologue and
epilogue generation? I could push $pc onto the stack just after
setting $fp, so it's
Doh, I suppose what I want is $sp, no, $fp, but that's where I'm
storing it, so I suppose I could just set $sp from $fp+const, yes?
It's an extra restore sp from fp but only when the frame size is
variable.
m32c-elf, gcc.dg/torture/stackalign/nested-1 at -O0,
produces this code:
_bar.1229:
enter #0
pushm r1,r2,r3,a0,a1
; end of prologue
mov.l a0,r3r1
add.l #-66,sp
stc sp,a1
. . .
ldc a1,sp
; start of epilogue
Couldn't GCC (and binutils) on djgpp set
_CRT0_FLAG_DISALLOW_RESPONSE_FILES so that GCC's routines get used
to expand the response files instead of the runtime's routines?
I suppose it could. I'm not sure how much confusion that would cause
(probably little if any), but as long as djgpp
Ian Lance Taylor i...@google.com writes:
I believe lThese option files were adapted from Windows, and they are
primarily for use on Windows, which has much stricter limits on command
line length than most Unix systems. We should implement whatever
Windows implements.
IIRC they were adapted
The GNU doschk (in non-gnu/) utility can tell you what's legal and what isn't.
http://www.delorie.com/gnu/dl/ftp.gnu.org/non-gnu/doschk/doschk-1.1.tar.gz/doschk-1.1/doschk.c
Note, however, that @files used by gcc *in djgpp* will *not* support
comments, because @files in djgpp are parsed and
pr45055 tests a scheduling fix, but on targets that don't support
scheduling (like m32c-elf), gcc emits a warning that scheduling is not
supported. This warning causes the test to fail. How do we bypass
these types of test cases? I don't see a suitable effective_target
for scheduling.
spawn
http://gcc.gnu.org/rsync.html says 17 Gb.
I just did it, and it's up to 22 Gb.
This is OK if you add LABEL_ALIGN_MAX_SKIP, LOOP_ALIGN_MAX_SKIP,
LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP, and JUMP_ALIGN_MAX_SKIP to the
/* Old target macros that have moved to the target hooks structure. */
#pragma GCC poison list in system.h.
Thanks, committed with that change.
DJ Delorie d...@redhat.com writes:
JUMP_ALIGN_MAX_SKIP
LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
LOOP_ALIGN_MAX_SKIP
LABEL_ALIGN_MAX_SKIP
None of these macros take any parameters, but for optimal performance
on RX, it's key to match the max_skip with the size of the following
opcode
DJ, can you amend your scripts so that the head of gcc/ChangeLog and
src/ChangeLog is included? This will make it easier to bug relevant
people.
Done.
In this example, why isn't insn 117 scheduled before insn 115 ? What
is the dependency? The only thing they have in common is CC, but both
generate a value which is never used.
;; ==
;; -- basic block 15 from 114 to 118 -- after reload
I think it's probably a mistake to have the default ADD
instruction SET the flags, rather than CLOBBER them.
How else would we optimize away compares?
Would we have to do that for *all* the math/logic ops, or just add?
That said, I suppose it wouldn't hurt to modify sched-deps
to treat a SET+REG_UNUSED as a CLOBBER.
Early in sched_analyze_reg, check for ref==USE and a REG_UNUSED note,
and change ref to CLOBBER? I tried it, it didn't seem to help...
Index: sched-deps.c
Is there a particular target you're interested in?
Not in that way, no. My biggest concern is that the documentation is
wrong. My second concern is that the help option says it basically
does nothing (well, one or two options) instead of the big list it
used to do (or that the other -O* do).
The docs say...
@item -Os
@opindex Os
Optimize for size. @option{-Os} enables all @option{-O2} optimizations that
do not typically increase code size. It also performs further
optimizations designed to reduce code size.
@option{-Os} disables the following optimization flags:
Some backends also check optimize_size to change their cost algorithms
to favor shorter instruction sequences.
But why doesn't it do what the documentation says? -falign-* seems
like an obvious one - aligning labels and such always makes the code
bigger.
JUMP_ALIGN_MAX_SKIP
LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP
LOOP_ALIGN_MAX_SKIP
LABEL_ALIGN_MAX_SKIP
None of these macros take any parameters, but for optimal performance
on RX, it's key to match the max_skip with the size of the following
opcode - there's a penalty only if you branch to an
I think I've seen this one, it's something like this: GNU flex calls M4
when you run flex. GMP disables M4 and runs flex; flex then tries to
run m4-not-used (or whatever it's called) instead of m4.
In unroll_loop_runtime_iterations() we emit a sequence of n_peel
compare/jump instructions. Why don't we honor
TARGET_CASE_VALUES_THRESHOLD here, and use a tablejump when n_peel is
too big?
Can we similarly promise or say something for accesses of the
containing struct as a whole?
I hadn't considered those cases (when would you want to copy a
*peripheral* ?) Should be the same as before, I would think.
Robert Dewar de...@adacore.com writes:
I would create a specific committee to reccommend a C++ coding
standard (preferably based on one of the standard ones available, such
as Google).
Doing things in secret like that is not the Open Source Way.
You've already convinced me, but you originally described a problem
where emacs' paragraph formatting would incorrectly rearrange
multi-line C++ comments. Out of personal curiosity, does emacs
actually have a bug in this regard or not?
It happens to work correctly in a well-formed C++ test
My suggestions:
* When it is appropriate to use a child class with virtual functions,
the virtual functions should all be declared as protected in the
parent class.
At first reading, I thought you meant all virtual functions should be
protected, but I think you meant if a child ADDS a
Diego Novillo dnovi...@google.com writes:
4- Should we make the switch during the 4.6 stage 1?
My suggestion: put something in one common file that requires C++, just
to force the use of C++ compilers, but with a comment that says If you
can't build this file, comment out the following and file
I did mean that all virtual functions should be protected.
This forbids the most useful thing about virtual functions - letting
child classes implement a public ABI defined by the base class.
* All data members should be private.
* All data members should have names which end with an
In a project with as many globals as we have, it's kinda handy to
know at a glance whether a member function is accessing a data
member or a global.
Add a globals-in-namespaces rule, or a ::global syntax, and you have
even more overkill.
IMHO we should make it easy to implement a clean
2) The parent class does not consist only of pure virtual methods.
In that case I am arguing that all virtual methods should be
protected.
What about the case where the parent provides default implementations
of methods that are infrequently overridden by children? Otherwise,
you end up with
Right, but it may happen some day. Also there is the issue of
clarity. I think it is clearer to see this-get() rather than get().
this-put_size (this-get_bounds (this-get_x(), this-get_y()),
this-get_variance (this-default_variance ()))
I'd like to avoid needing to assign
gold is using this convention, isn't it?
I find the gold sources harder to read than the rest of binutils, and
would like to avoid propogating that style elsewhere. This from
someone who's been writing C++ code for twenty years now.
Also, gold was added to binutils without this type of
Hargett, Matt matt.harg...@bluecoat.com writes:
As noted earlier I think we do want to use some STL classes.
I agree with Mark's earlier declaration that it is relatively
straight-forward, low-hanging fruit to replace VEC_*
I do not object to simple and obvious uses of STL to replace
Mark Mitchell m...@codesourcery.com writes:
So, my question is this: is the permission above sufficient for what
people want to do at this point?
This permission exactly covers what libiberty does for its
documentation, you can use that as an example to RMS.
Can we make a point of not using Cpp as a normalization of C++ ?
I keep thinking it's referring to the C preprocessor. Cxx is less
misleading (and kinda looks the same), when C++ cannot be used for
character set reasons.
I think that would be most unproductive and misguided.
Maybe I should step back and restate my original desires.
I don't want us to move *too quickly* towards an all-STL
implementation, and end up with a hairy mess that's hard to
understand. I've had to debug our STL implementation before,
Also, I would like to make a new policy that from now on patches to
the toplevel cannot be committed by anyone who doesn't have write
access to both gcc and src. Is there any agreement on this?
Our current policy certainly doesn't work, either we come up with
something that will, or abandon
There are no changes in intl, libiberty. The sourceware git mirror
doesn't seem to carry libdecnumber. Which files in include/ were
part of libiberty again?
Libiberty is kept in sync because gcc is the master and src is the
copy, so it can be mostly automated. The libiberty sync includes
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?
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 only
Yes, but presumably you could make those pseudo-ops ARM-specific,
rather than EABI specific?
Could, but gcc doesn't always know the specific .fpu. I imagine
version-sync nightmares too, so IMHO we should either do a
command-line thing from gcc, or just forget it if EABI works.
If it isn't, then you can either punt on arm-elf, or enable some
EABI functionality there. If, on the other hand, you think there's
a problem when using the EABI, then we should talk about how to
solve it.
EABI works fine, we're just working through our array of
things-to-be-tested and
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?
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)
+++
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
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
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?
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.
Note that the m32c port uses PSImode, so it may offer some suggestions
as example code.
Libiberty should not even try to compile psignal() on djgpp as djgpp
already has one. This is noted in libiberty/configure.ac.
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?
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,
* DJGPP
Committed.
2009-08-13 DJ Delorie d...@redhat.com
* config/i386/djgpp-stdint.h: New.
* config.gcc (djgpp): Use it.
Index: config.gcc
===
--- config.gcc (revision 150731)
+++ config.gcc (working copy
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,
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-32C
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
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
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 that the
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
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
Thanks, committed.
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
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
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
This is a special case because all the logic has to be done in md5.c
as preprocessor macros. You'd need someone familiar with the platform
(Chris, Danny, Kai) to specify a reliable way to detect that platform
and/or define the types accordingly. If it can typedef md5_uintptr
directly, or use
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
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?
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.
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? ;-)
Pending initial (technical) approval
Ping? Still waiting for technical approval from a global maintainer.
http://people.redhat.com/dj/mep/
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 output
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
Pending initial (technical) approval
So... Can I get a global maintainer to approve it?
Thanks!
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
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
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,
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.
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
Andrew Pinski pins...@gmail.com 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
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 that
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.
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 doubles),
and adjusts some of the tests
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.
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)
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 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.
701 - 800 of 1257 matches
Mail list logo
