Please may I apply the patch below. It fixes the RL78 backend so that
the stack register can be used as a base address register.
Yes, please. Thanks!
I think that's right, since the ISR return restores the flag register,
which has the bank select bits in it.
I did notice that the hardware didn't work the same way as the
documentation... this would explain it. Yes, please apply it :-)
The official DJGPP triplet is for i586, not i386. I don't mind
djgpp-wise if we deprecate i386, as long as we keep i586. Anyone
still using djgpp for i386 can dig out old versions from the archives :-)
Marketing loves high numbers after all!
If you truly think this way, we're going to have to revoke your hacker's
license ;-)
This patch allows the user to specify a vector number in an interrupt
attribute, allowing for more generic creation of vector tables. Ok?
* doc/extend.texi (Function Attributes): Document RX extensions to
interrupt attribute.
* config/rx/rx.c (has_interrupt_vector): New.
Ian Lance Taylor i...@google.com writes:
Also the fact that GCC is now written in C++ seems to me to be
deserving of a bump to 5.0.
I see no reason why an internal design change that has no user visible
effects should have any impact on the version number.
Typically a major version bump is
Commited.
* config/rl78/rl78.c (rl78_as_legitimate_address): Do not allow
reg+addend addresses for the _far namespace.
Index: gcc/config/rl78/rl78.c
===
--- gcc/config/rl78/rl78.c (revision 192862)
+++
Fixed 16-bit widening multiplies by a constant by limiting constant
matches to 16 bit constants. Applied.
PR target/54950
* config/m32c/predicates.md (m32c_const_u16_operand): New.
* config/m32c/muldiv.md: Use it.
Index: config/m32c/predicates.md
Are you sure you meant to have an fprintf in a match_test ?
I definitely did not. Removed. Thanks!
Why do you need to change varasm.c at all? The hunks seem to be
completely separate of the attribute.
Because static constructors have fields in the original order, not the
reversed order. Otherwise code like this is miscompiled:
struct foo a = { 1, 2, 3 };
because the 1, 2, 3 are in the
ChangeLog missing, new functions need a toplevel comment documenting
function, argument and return value as per coding conventions.
Any review of the patch itself? I know the overhead is not there...
Here's my current patch for the bitfield reversal feature I've been
working on for a while, with an RX-specific pragma to apply it
globally. Could someone please review this? It would be nice
to get it in before stage1 closes again...
Index: gcc/doc/extend.texi
[sorry, should have gone to gcc-patches]
Is there any automation for this or is it still up to each person
checking in files to copy stuff over by hand?
There is no automation, as neither project was willing to cede control
to the other. In general, any patch applied to one repo should be
(and may be) applied to the other, but at
I don't feel the m32c change needs my specific ack, it's a harmless
change that goes with the ack for the feature itself.
However, I will note that m32c does have different costs for addresses
in different address spaces, at least when -Os.
I ran the testsuite for you; no regressions. Looks OK to me, please
apply. Thanks!
Date: Tue, 5 Jun 2012 21:59:15 -0400 (EDT)
From: Hans-Peter Nilsson h...@bitrange.com
On Fri, 25 May 2012, DJ Delorie wrote:
If I apply this patch, which checks for duplicate hard registers within
-fira-share-save-slots, the following *-elf targets fail due to the assert:
bfin cris
The issue is that using the plugin interface makes breakage only
detectable when you are able to test a target, not by merely
building it.
You just described *most* of the bugs I have to deal with.
RTL checking pointed out a couple of cases where rl78.c was extracting
info from rtx without checking the rtx type first. Applied.
2012-08-09 DJ Delorie d...@redhat.com
* config/rl78/rl78.c (rl78_alloc_physical_registers): Check for
SET before extracting SET_SRC
But we should definitely have a way to register machine dependent
passes, and what's wrong with the plugin interface?
IIRC I asked about how to schedule that pass when I wrote it, and use
the plugin API was the recommendation.
Some background...
The RL78 devirtualization pass is *not* a
Gosh, we got one of those too, though, I don't know how much worse
your machine is than mine, in at all.
In the RL78 case, it's basically a modern Z80 clone. It has eight
8-bit registers (er, four banks of those, one active at a time) which
can be combined into four 16-bit registers, but for
That's fine with me.
Testing on m32c reveals that we've been asking for cost of
conversion from MODE_PARTIAL_INT. We hadn't actually been
initializing those costs, mind.
Ah, ignore my previous email in the m32c thread then ;-)
I tried to test this, but newlib won't build (looks unrelated). The
failure is this assert in expmed.h:
gcc_assert (to_mode = MIN_MODE_INT
to_mode = MAX_MODE_INT
from_mode = MIN_MODE_INT
from_mode = MAX_MODE_INT);
which can't possibly work on any
Ah, the original complaint was for a gcc branch which doesn't have
your strict-dwarf/discriminator patch.
How's this?
Index: gcc/config/s390/s390.c
===
--- gcc/config/s390/s390.c (revision 190017)
+++ gcc/config/s390/s390.c
TARGET_TPF is always defined. Just use a C if.
Otherwise ok.
Thanks, checked in as attached.
What about older branches? 4.7 needs this patch, 4.6 needs my
original patch.
2012-07-31 DJ Delorie d...@redhat.com
* config/s390/s390.c (s390_option_override): Disable DWARF 3/4
I don't see that 4.6 requires a different patch.
4.6 is missing this:
2011-04-01 Richard Henderson r...@redhat.com
PR 48400
* dwarf2out.c (dwarf2out_source_line): Disable discriminators
in strict mode before dwarf4. Re-order tests to early out
before
The TPF assembler supports dwarf4 discriminators, but the TPF
debuggers do not. Ok to apply?
* config/s390/tpf.h (SUPPORTS_DISCRIMINATOR): Define to 0 for TPF.
Index: gcc/config/s390/tpf.h
===
--- gcc/config/s390/tpf.h
I wonder if registering a handler for invalid parameters, at least
around those calls, so that we can enforce the posix-like return an
error semantics?
OK for mainline?
Ok.
2012-07-26 Kazu Hirata k...@codesourcery.com
Sandra Loosemore san...@codesourcery.com
libiberty/
I think it's confusing to have filename_cmp and filename_eq that do
basically the same thing. Perhaps filename_eq should be
filename_cmp_v or filename_cmp_hash or something, to indicate that
it's *supposed* to be the same functionality as filename_cmp but with
a different signature?
If there's precedent, I'm not worried about it.
Ok to check in.
My concern is more about calling NEXT_INSN on a deleted insn. If
that's guaranteed to be reliable, I'm OK with it.
Alternately, call NEXT_INSN at the top of the loop, but save the value
until the *next* iteration of the loop, so we can delete the insn and
not have to call NEXT_INSN on it after
Let me try again then...
RL78 is confusing and it took a while to get it to work right. Please
don't change it ;-)
But we can certainly remove stuff that doesn't do anything; in particular,
these 3 lines
/*#define DONT_USE_BUILTIN_SETJMP 1*/
#undef DONT_USE_BUILTIN_SETJMP
#define JMP_BUF_SIZE (8*3+8)
can be proved to be equivalent to the empty set.
If you say so, go for it ;-)
The rl78 apparently doesn't know what it wants to do:
/* NOTE: defined but zero means dwarf2 debugging, but sjlj EH. */
#define DWARF2_UNWIND_INFO 0
/*#define DONT_USE_BUILTIN_SETJMP 1*/
#undef DONT_USE_BUILTIN_SETJMP
#define JMP_BUF_SIZE (8*3+8)
But I'll leave that to an rl78
OK to commit this amended patch?
Ok. Do we have a build-with-c++ FAQ page anywhere? /me thinks it
will be useful soon ;-)
BUILD_CFLAGS= @BUILD_CFLAGS@ -DGENERATOR_FILE
+BUILD_CXXFLAGS = $(INTERNAL_CFLAGS) $(CXXFLAGS) -DGENERATOR_FILE
Why are these so different?
The rest seem OK
If I apply this patch, which checks for duplicate hard registers within
-fira-share-save-slots, the following *-elf targets fail due to the assert:
bfin cris m32c rl78 rx sh sh64 v850
It'd really help if you could probably a testcase so that we could run
things under a debugger
dj@greed pts/0 ~/m32c/gcc/rl78-elf/gcc
$ ./cc1 -quiet -O3 qsort.i
DJERR: DUPLICATE HARD REG 12
../../../../../src/newlib/libc/search/qsort.c: In function 'qsort':
../../../../../src/newlib/libc/search/qsort.c:222:1: internal compiler error:
in setup_save_areas, at caller-save.c:574
Please
If I apply this patch, which checks for duplicate hard registers within
-fira-share-save-slots, the following *-elf targets fail due to the assert:
bfin cris m32c rl78 rx sh sh64 v850
The following succeed:
frv h8300 i386 ia64 m32r mep mipsisa32 mipsisa64 mn10300 powerpc tx39
gcc/
* ira.c (pseudo_move_insn): Delete.
(find_moveable_pseudos): Don't set it.
(move_unallocated_pseudos): Use DF_REG_DEF_CHAIN to find
the definitions of the original pseudo. Delete all of them.
I can build with this. Thanks!
For rl78 there is a comment in gcc/config/rl78/rl78.h that suggests
there should be a tablejump insn, but it's not there.
The only unconditional branches rl78 has are immediate and
register-indirect, i.e. BR $label and BR AX.
This is unfortunate because rl78 is a #define DWARF2_UNWIND_INFO 0
After r187015 (Mar 31), gcc builds for rx-elf are failing with:
make[3]: Entering directory
`/greed/dj/m32c/gcc/rx-elf-head/rx-elf/64-bit-double/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/greed/dj/m32c/gcc/rx-elf-head/./gcc/xgcc
Can any of these stubs throw exceptions? What are they used for?
I suspect they're simple thunks. I can ask what they do.
My first reaction is to simply consider them invisible system frames
and ignore them when it comes to unwinding...
That's what we're trying to do, but the CFA
I'm a bit confused as to how the fallback handler can find the correct
RA but the normal unwind path can't.
The fallback knows what address range corresponds to the stubs. It's
magic.
How do all these things fit on the stack?
Every stack frame has room for two return addresses.
The stub
style nits: It should be size_t(__len - __pos), and not
(size_t)(__len - __pos). Same for the other hunk. Patch OK with
those changes.
Committed that way. Thanks! Ok for 4.7 branch as well?
* include/bits/random.tcc (seed_seq::generate): Cast max()
operands to size_t to
Committed that way. Thanks! Ok for 4.7 branch as well?
yes, it is. Thanks,
Done!
Regardless, shouldn't DWARF2_ADDR_SIZE be POINTER_SIZE / BITS_PER_UNIT?
That's the default. It doesn't work because pointers are still 16 bits.
That's the default. It doesn't work because pointers are still 16 bits.
Something's still not right then. The H8/300 has 16 bit pointers and a
64k address space and all the processors in the family still support
that mode.
The problem is when a single object is more than 64k for the
Whereas making dwarf addresses always 32 bits only affects debugging
info size (not rom image size) on the oldest and smallest H8/300
variant, where real-world code would have a limited amount of debug
information anyway.
A TPF stack frame has up to two return addresses in it. The second
one is used when the call crosses a shared object domain, where a stub
is between the two functions. The stub does not change the stack, but
it does eventually chain to the correct return address.
In the TPF unwinder, a
OK to apply ?
Ok. Thanks!
H8/300 cpus have a larger-than-64k address space, despite 16-bit
pointers. OK to apply? Ok for 4.7 branch?
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231
* config/h8300/h8300.h (DWARF2_ADDR_SIZE): Define as 4 bytes.
Index: h8300.h
I assume this is a size_t vs int type problem, but the diagnostic
points to the function declaration, not to an actual binary
expression, and I can't figure out what it's complaining about:
/greed/dj/m32c/gcc/h8300-elf/./gcc/xgcc -shared-libgcc
-B/greed/dj/m32c/gcc/h8300-elf/./gcc -nostdinc++
#define q ((char *)0x1234)
foo(int x)
{
*q |= (1 (char)x);
}
$ m32c-elf-gcc -S -O3 nick.c
.global _foo
_foo:
mov.w r1,a0; 20
movhi_op/3
bset4660[a0] ; 11
Make sure a match_dup will still match the generated pattern later,
I've had problems with match_dup not matching two rtx that
rtx_equals() says are the same but not physically the same.
* crossconfig.m4: Since we know that all TPF builds are cross-
builds and cannot run configuration-time link tests, do not
allow it; just go with known supported linker options.
* configure: Regenerate (called as GLIBCXX_CROSSCONFIG).
OK
Thanks! Committed.
* crossconfig.m4: Since we know that all TPF builds are cross-
builds and cannot run configuration-time link tests, do not
allow it; just go with known supported linker options.
* configure: Regenerate (called as GLIBCXX_CROSSCONFIG).
Index: crossconfig.m4
Set up a cron job to ping once a day. :-) Did you ever dig up the
Apple test cases from the APPLE LOCAL work I pointed you at earlier?
They will be more comprehensive that any testing you've done, and,
if you get them to all pass, the work should be closer to being
complete. The feature
Initial implementation of RTX_COSTS target function for rx-elf. Minor
increase in coremark scores, and enables division by multiplication of
reciprocals, tested on trunk and 4.7. Ok for trunk and/or 4.7 branch?
* config/rx/rx.c (TARGET_RTX_COSTS): Define.
(rx_rtx_costs): New.
I will not oppose adding more unrelated stuff to libiberty, but
neither will I approve it. I will let one of the other maintainers or
a global maintainer approve it.
Per request from IBM...
* config/s390/s390.h (LINK_SPEC): Remove, no longer needed.
(LIBSTDCXX): Change to CPP2.
Ok.
Bye,
-Andreas-
Thanks! Committed.
* config/s390/s390.h (LINK_SPEC): Remove, no longer needed.
(LIBSTDCXX): Change to CPP2.
Can one S390 maintainers approve this please?
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01545.html
The optimization pass flag TODO_dump_flag has been removed (see
patch committed 2012-04-11) which was causing the RL78 backend to fail
to build. I am applying the following patch as an obvious fix.
Ok, thanks!
Michael Matz m...@suse.de writes:
syntactic noise without any whitespace. Quite frankly, how anyone could
ever say that
exp-as_component_ref().get_field()
is easier to read/write/use than
GET_FIELD_DECL (exp)
C vs C++ is not the same argument as style A vs style B. Your argument
OK for mainline/4.7 branch ?
Ok with me
Did you ever dig up the Apple test cases from the APPLE LOCAL work I
pointed you at earlier?
Sorry, I read that as the internal tree at Apple not the apple
branch at fsf. I'll look at it, thanks!
They will be more comprehensive that any testing you've done, and,
if you get them to all
If it's required for ABI compatibility why is this an attribute and not
a target hook?
The ABI uses a #pragma; after this is in I'll do a target-specific
pragma handler to set the attribute. Plus, when I originally proposed
the idea, I was told it was generic so make it an attribute ;-)
Ping 6...
It's now been over EIGHT MONTHS since I posted the patch, back in
stage 1 for 4.7. Can someone please review and/or approve this before
gcc 4.8's stage 1 is closed? This is needed as a first step for ABI
compatibility for rx-elf.
Ping 5...
Ping 4...
Ping 3? It's been
Per request from IBM...
* config/s390/s390.h (LINK_SPEC): Remove, no longer needed.
(LIBSTDCXX): Change to CPP2.
Index: config/s390/tpf.h
===
--- config/s390/tpf.h (revision 185677)
+++ config/s390/tpf.h
But given the pushback for even one new library, I think we're
unnecessarily slowing ourselves down.
I'm not opposed to libiberty becoming the kitchen sink, if that's what
people want. If it does go that route, my reason for being a
libiberty maintainer no longer applies, and others who are
This breaks constructors on pretty much every elf+newlib target,
because newlib and gcc both use HAVE_INITFINI_ARRAY (and have for many
years) but the tests don't match. GCC puts ctors in .ctors but libgcc
is built without support for them (newlib's generated config headers
define
Sweet! Thanks! We hadn't merged that bit into our tree yet...
configure has various ways of specifying the target headers for a
cross-compiler. However, none of these work when you're
cross-building a native (build!=host==target). Unfortunately,
configure looks in $target_header_dir for target headers to determine
various bits of functionality.
What is
My first try would be --with-build-sysroot. Does that fail in some way?
It's ignored without --with-sysroot, but if you use --with-sysroot,
the cross-built native *also* expects to use a sysroot, which means
binutils must also be built with a sysroot, even if its /.
OK, but what's wrong --with-sysroot=/ ?
It should work, it just seems wrong for a native compiler to have a sysroot...
Sigh, libiberty is supposed to be a portability library, not a
kitchen-sink for common stuff. Should I give up that premise? Or
should we consider a common dwarf2 helper library, and move even more
of the dwarf2 code into it?
First, you'll notice that the first constant for a given enum is
Finally, there is already stuff in libiberty not related to
portability. E.g., hashtab or the demangler.
Yeah, I know, hence my Should I give up that premise?
I guess I can just put the whole DW_TAG_ prefix in there. That
isn't a big deal. Or if you have some other suggestion, I can
Looks OK to me.
Ping - http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00549.html
And now really add Paolo and DJ.
+ [.type foo, '$target_type_format_char'gnu_unique_object],,
This un-quoting looks incorrect if you don't know what's going on
under the hood, but I don't see a clean way around it. A
This is DJ's baby, let's see whether he has an alternate site?
Sorry, I got nothin'
I would classify these as obvious but please make sure they go in
before the poison patch ;-)
And this will be needed to make those ports do what was intended:
* config/rl78/rl78.h: Replace SMALL_REGISTER_CLASSES with hook.
* config/rx/rx.h: Remove SMALL_REGISTER_CLASSES.
The typo is obvious, but whether or not the wrapped code still works
isn't (to me).
* src/c++98/locale.cc (locale::facet::_S_get_c_locale): Fix
typo.
Please check this in.
Done. Thanks!
Ping 5...
Ping 4...
Ping 3? It's been months with no feedback...
Ping 2 ?
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00529.html
Jan Kara j...@suse.cz writes:
we've spotted the following mismatch between what kernel folks expect
from a compiler and what GCC really does, resulting in memory corruption on
some architectures. Consider the following structure:
struct x {
long a;
unsigned int b1;
unsigned
Ping 4...
Ping 3? It's been months with no feedback...
Ping 2 ?
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00529.html
and I think applying strict-volatile-bitfields to enums is probably
meaningless.
MCU vendors would disagree. If a location is volatile, it's most
likely hardware, and must be accessed in the user-specified way.
Randomly accessing adjacent locations could cause system failure.
I have no problems running make pdf in libiberty.
texi2dvi (GNU Texinfo 4.13) 1.135
Ah! I read that as pointer to aggregate :-P
For the record, what is TPF ?
One of IBM's s390x operating systems. ../gcc/configure --target=tpf
That should not be necessary as there is a mode check below. Do you
hit the issue only when the VOID_TYPE_P check is true? In that case
simply delete it - it has become obsolete.
That seems to be happening, yes, but there are other checks
that might let differing modes through...
/*
Thanks, committed.
Another case where one address space may support multiple pointer
sizes, so conversions between such must be preserved.
* tree-ssa.c (useless_type_conversion_p): Conversions between
different-sized pointers aren't useless.
Index: tree-ssa.c
The assert is not valid for address spaces that support more than one
pointer size, such as the generic space of TPF, mips64, or m32c.
2012-01-11 DJ Delorie d...@redhat.com
* cfgexpand.c (convert_debug_memory_address): Allow any valid
pointer type, not just the default pointer
Ping 3? It's been months with no feedback...
Ping 2 ?
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
On Tue, Dec 20, 2011 at 04:04:16PM -0800, Brendan Conoboy wrote:
On Tue, Dec 20, 2011 at 2:37 PM, Jakub Jelinek ja...@redhat.com wrote:
This is ok for 4.6 if it has been sufficiently tested.
Okay! Is there any testing you'd like to see beyond the
aforementioned success with arm and
This field is built as a gcov_unsigned_t but declared
as a plain unsigned, which breaks all int16 targets:
/* n_functions */
field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE,
get_gcov_unsigned_t ());
DECL_CHAIN (field) = fields;
fields = field;
Assuming
Committed. Fixes issues with the full epilogue not being emitted.
* config/rl78/rl78.md (return): Rename to rl78_return.
* config/rl78/rl78.c (rl78_expand_epilogue): Use new name.
(rl78_expand_eh_epilogue): Use new name.
(rl78_calculate_death_notes): Likewise.
Excellent. Thanks!
501 - 600 of 1257 matches
Mail list logo
