Committed. Thanks!
+ yes|no) AC_MSG_ERROR([bad value ${withval} given for
--with-native-system-header-dir]) ;;
+ /*) ;;
+ *) AC_MSG_ERROR([--with-native-system-header-dir argument ${withval} must
be an absolute directory]) ;;
This doesn't handle DOS-style absolute paths (like c:/Users). Not
sure if we care
Ping 3 ? I'd like to get this in before stage1 ends... There's
RX-specific code that goes with it that can't go in until the core
functionality is approved.
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
There are some gcc flags that are not legal g++ flags, though...
Hmm... ok, I'm just a tad paranoid about using the name CFLAGS for
g++, someone's bound to do the stupid thing eventually.
Do I need to sync the config and libiberty parts to src manually or does
this happen by some sort of magic?
intl/; config.rhost; libiberty/; libiberty's part of include/
gcc: http://gcc.gnu.org
Changes need to be done in tandem with the official GCC
sources or
Ping 2 ?
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02555.html
OK to install?
* config/m32c/m32c.h (CLASS_MAX_NREGS): Remove macro.
* config/m32c/m32c-protos.h (m32c_class_max_nregs): Remove.
* config/m32c/m32c.c (m32c_class_max_nregs): Make static. Change
regclass argument type to reg_class_t. Change 'max' and 'v'
Ok.
Probably. Thanks for the leg-work. I'll approve the patch as-is.
May I apply it to the 4.5 and 4.6 branches? The same patch applies
as-is to both.
Seeing little opposition, I plod further... now with documentation
and a test case. OK yet?
Ping?
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html
Naked is related to TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS - ARM and RX
set the latter based on the former, and nobody else uses that target
hook. So, naked functions don't have stack slots for args. Without
stack slots, args can't be assigned to memory locations - even if
they're
Fails the same way with a parameter as with a local:
int result;
void __attribute__((naked)) ISRFunction(int x) {
result = subFunction(x);
}
but I'm certainly open to a better explanation of how a user program
can trigger an ICE that way.
Hmmm... the only use of
Thanks! Committed.
So don't lie to GCC then? You specify
struct X { char c; int i; } __attribute__((packed)) x;
and expect that GCC knows x.i is aligned to 4 bytes!?
The actual header is much more complex than this trivial example.
It also fails with this example, where the port_status[] array *is*
If a function is both a leaf function and an interrupt function, leaf
register renumbering causes the wrong set of registers to be saved.
This patch disables renumbering for interrupt functions.
* config/rx/rx.c (rx_leaf_registers): New.
(rx_set_leaf_registers): New.
This patch tests for at least one user-caused reason for this
assertion failing - requiring a local frame in a naked function. For
this case at least, it would be better to trigger an error than to
ICE. OK?
static int bar;
void __attribute__((naked)) function(void) {
int foo, result;
Fact is that GCC knows that memory is not properly aligned.
So in the impossibly rare case that gcc is *wrong*, how is the
programmer supposed to tell gcc that? I mean, gcc 4.4 has been doing
what the programmer wanted, and zillions of ARM devices have been
happily working, and now you tell me
Ok.
I built an arm kernel with it, the USB stuff works.
I take that back - booted the wrong kernel. Didn't work, but I'll
confirm that I'm building with a patched gcc (too many kernels and
compilers to keep track of ;)
Yeah, the testcase is invalid - that we lost the volatile was a bug, but
you really have to fix the kernel.
Sadly, that's not a helpful suggestion. How else should the kernel
force a word-sized read? I thought volatile was the way to tell gcc
do exactly what I tell you to do ?
And the
I'm testing the following.
Richard.
2011-07-22 Richard Guenther rguent...@suse.de
PR tree-optimization/45819
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Properly
preserve volatile and notrap flags.
* gcc.dg/pr45819.c: New testcase.
I
Some targets (m32c, tpf, mips) have more than one pointer size. It is
not correct to assume that a pointer is POINTER_SIZE.
Index: gcc/cp/cvt.c
===
--- gcc/cp/cvt.c(revision 176554)
+++ gcc/cp/cvt.c(working copy)
@@
Seeing little opposition, I plod further... now with documentation
and a test case. OK yet?
Index: doc/extend.texi
===
--- doc/extend.texi (revision 176586)
+++ doc/extend.texi (working copy)
@@ -5089,12 +5089,74 @@ Note
In this PR, a cast to a volatile type is lost during forwprop1,
resulting in the wrong access semantics being used for a memory-mapped
peripheral register. Checking for loss of volatile in this patch
solves the problem, but I don't know if this is the right place to put
such a test - it could go
Finally getting around to writing this one. The idea is to have an
attribute which determines how bitfields are allocated within words
(lsb-first vs msb-first), assuming the programmer doesn't ask us to do
something impossible. __attribute__((bitorder(FOO))) where FOO is:
native (or omitted,
Ok for trunk?
Ok with me. I'll let the branch maintainers decide if they want it
for their branches.
Looks OK to me.
Since you feel so strongly about it and nobody objects, go ahead.
Backport to open branches? (And note PR48825.)
I've already given my OK, it's up to the branch managers to apply as
they see fit.
Ping.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02208.html
I don't have the bandwidth to work on the ideal patch. Thus I am
wondering if we can skip target-libiberty for androideabi target
before the ideal patch is out.
Target-specific changes in the build are up to the target
I never got feedback from the testsuite maintainers on this one...
Date: Mon, 9 Aug 2010 23:48:31 -0400
From: DJ Delorie d...@redhat.com
Mailing-List: contact gcc-patches-h...@gcc.gnu.org; run by ezmlm
Is there any reason why we don't support board-level timeouts? It's
really hard
Thanks! Committed.
hmm, yes. Again practically for most targets size_t will be
following its SIZE_TYPE advice, but surely not for all. OTOH while
the above clearly doesn't look accidential, it certainly looks
wrong. If not for sizetype then at least for size_type_node. The
comment hints that the patch at
Which means that Ada must be seriously broken on m32c (well, I guess
nobody tried it there ;)).
I usually only build C and C++.
Yes please. I've been arguing for that for some time.
Since you feel so strongly about it and nobody objects, go ahead.
http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html
http://gcc.gnu.org/ml/gcc/2010-03/msg2.html
http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html
there's nothing that could affect them.
Famous last words :-)
[build] More --enable-threads cleanup
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00059.html
This might well be obvious.
Also, we usually leave those up to the target maintainers, since
they're target specific. But if it's just a correlation between the
script and a list of
And the problem is that libiberty is assuming that it *knows* what
functions newlib provides, so that it doesn't need to check
directly. This is just broken...
Historically, cygwin was built using libiberty and newlib, so you did
not have a runtime at the time you were building libiberty,
What about these?
dependencies = { module=all-target-fastjar; on=all-target-libiberty; };
dependencies = { module=all-target-libobjc; on=all-target-libiberty; };
dependencies = { module=all-target-libstdc++-v3; on=all-target-libiberty; };
* strsignal.c (psignal): Change second parameter to const char *.
Fix comment accordingly.
OK.
I had argued against this patch:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00439.html
The newlib change broke ALL released versions of gcc, and the above
patch does NOT fix the
So regardless of whether the changes to newlib are a good idea or not, I
think the fix to libiberty is still right.
Irrelevent. I said I'd accept that change *after* the real problem is
fixed. The real problem hasn't been fixed.
The real problem is that libibery should NOT INCLUDE PSIGNAL
Thanks. I just have no check in rights to the gcc repository. I
applied the change to the sourceware CVS repository but for gcc I
need a proxy.
Please, never apply libiberty patches only to src. They're likely to
get deleted by the robomerge. The rule is: gcc only, or both at the
same
What I don't understand is why the newlib change broke older compilers.
Older compilers have the older libiberty. At the moment, libiberty
cannot be built by *any* released gcc, because you cannot *build* any
released gcc, because it cannot build its target libiberty.
The function has been
Occasionally, gcc passes a barrier instead of a label. This
accomodates such an event. Applies to 4.6 and trunk, and needed on
both to build newlib. Ok?
* config/rx/rx.c (rx_align_for_label): Don't test for
LABEL_NUSES on a barrier.
Index: gcc/config/rx/rx.c
This adds a simulated conditional execution option to the RX backend.
The RX can do a short conditional forward branch faster than a regular
conditional branch (1 byte, 1 cycle!), as long as it's only branching
across one or two insns. This patch encourages this behavior via the
condexec
OK to check in?
Ok with me. Thanks!
2011-05-06 Philipp Thomas p...@suse.de
* config/mep/mep.c (mep_validate_vliw): Syntax description
should not be translated.
I don't know how to avoid this problem in configure, other than by adding
AC_LIBOBJ([psignal]).
Right, the correct solution is - libiberty shouldn't provide psignal
if newlib does. Making it match newlib is the wrong solution.
You don't mean the prototype, do you? IMHO the char * should still be
changed to const char * to adhere to POSIX.
So far, it's served as a good tool for detecting when libiberty's
configure isn't doing its job :-)
At this point, we should avoid fixing it until the newlib/configure
issue is
* config/mep/mep.c (mep_init_builtins): Call build_function_type_list
instead of build_function_type.
Ok.
The m32c one is OK
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
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 :-)
501 - 558 of 558 matches
Mail list logo
