Alexandre Oliva writes:
> This looks like a latent bug in the port.
I'm not surprised, that port was weird.
> This was just a plain asm insn in strub.c:
>
> /* Make sure the stack overwrites are not optimized away. */
> asm ("" : : "m" (end[0]));
>
> whose constraint passes during reload, r
"Maciej W. Rozycki" writes:
> My interpretation of this would be for modifications rather than original
> sources, so v3+ applies to unmodified sources (for obvious reasons, given
> that the recipient of the sources is not a copyright holder), however as a
> copyright holder I can release my m
Paul Koning via Gcc writes:
>> GCC's license is "GPL version 3 or later", so if there ever needed to be a
>> GPL v4, we could move to it without needing permission from anyone.
>
> I don't think that is what the license says. It says:
>
> GCC is free software; you can redistribute it and/or modif
Jeff Law writes:
> A change in reload back in 2016 (IIRC) has effectively made m32c
> unusable. The limits of the register file create horrible problems for
> reload.
>
> I was going to suggest deprecation for gcc-8 given how badly it was
> broken in gcc-7 and the lack of maintenance on the targ
Jeff Law writes:
> I was going to suggest deprecation for gcc-8 given how badly it was
> broken in gcc-7 and the lack of maintenance on the target.
As much as I use the m32c target, I have to agree. I've tried many
times to fix its reload problems to no avail, and just don't have time
to work o
Jason Merrill writes:
> I'm inclined to change the C++ FE to pass NULL_TREE instead until such
> time as someone cares.
The sh backend will at least not choke on that ;-)
In my original proposal, I said this:
> It includes a bunch of macro->hook conversions, mostly because the
> hooks need an additional parameter (the function) to detect which ones
> are Renesas ABI and which are GCC ABI.
The original documentation at least hinted that the parameter was a
functio
Seima Rao writes:
> Has gcc become proprietory/commercial ?
By definition: no, yes. It's been this way since the beginning, and
hasn't changed in decades.
> Or has it become illegal to publish specification models
> of gcc internals ? Does this make the product sell less ?
This
Manuel Lpez-Ibñez writes:
> Another question is how to help existing maintainers such that they
> are more motivated to review patches. Is it a lack of time? lack of
> Interest in the project? do patches simply fall through the cracks? is
> it a dead-lock of people waiting for each other to comme
Manuel Lpez-Ibñez writes:
> I don't see how that helps. Neither my message nor Thomas's is a
> criticism of people. The question is how to get more people to help
> and how to improve the situation. For sure, everybody is doing the
> best that they can with the time that they have.
You complaine
Manuel Lpez-Ibñez writes:
> none? for libiberty, no regular maintainer for build machinery,
Perhaps this is a sign that I should step down as maintainers for those?
David Edelsohn writes:
> GCC on the system is not self-hosting -- I believe that GCC only is
> used as a cross-compiler.
I can confirm this - GCC for TPF is always a cross compiler, it never
runs *on* a TPF system.
Given how many embedded ports have #defines in external packages for
basic asms for instructions such as nop, enable/disable interrupts,
other system-level opcodes, etc... I think this is a bad idea. Even
glibc would break.
#define enable() asm("eint")
__asm__ __volatile__ ("fwait");
> Given a combination of "I have new responsibilities" and "nothing has
> happened with mep for a long time" I would like to step down as mep
> maintainer.
>
> If someone would like to pick up maintainership of this target, please
> contact me and/or the steering committee. Otherwise, I propose
Consider this example (derived from gcc.c-torture/execute/920726-1.c):
extern int a(int a, int b, int c, int d, int e, int f, const char *s1, const
char *s2) __attribute__((pure));
int
foo()
{
if (a(0,0,0,0,0,0,"abc","def") || a(0,0,0,0,0,0,"abc","ghi"))
return 0;
return 1
Given a combination of "I have new responsibilities" and "nothing has
happened with mep for a long time" I would like to step down as mep
maintainer.
If someone would like to pick up maintainership of this target, please
contact me and/or the steering committee. Otherwise, I propose this
target
> I spec'd one out a long time ago for Cygnus/Red Hat, but we never
> pursued the port. The register model on the z80 will be problematical,
> though some of the lessons from the rl78 port would probably be useful.
The RL78 is very much a modern decendent of the Z80 architecture so might
serve
> So in general, it's really not safe to mark a constraint that accepts
> only far memory as "memory constraint" with current reload.
>
> Note that *not* marking the constraint as memory constraint actually
> does not prevent reload from fixing up illegitimate addresses, so you
> shouldn't really
Richard Biener writes:
>> Using d...@gcc.gnu.org would imply that is my email address, but email
>> sent there would vanish.
>
> Would it? You're supposed to have a valid forwarding address on that.
Frank tested it and it does seem to forward to me, so I guess so.
"Frank Ch. Eigler" writes:
> That makes sense, but how many people are in cagney's shoes
I am one of those people - I have two email addresses listed in
MAINTAINERS, with two sets of copyright papers filed with the FSF (a
personal assignment and a work one). I use the appropriate email
address
> And in fact, you should be able to decide at *expand* time which
> of the two you need for the given set of operands.
I already check for multiple fars at expand, and force all but one of
them to registers. Somewhere before reload they get put back in.
>"rl78_virt_insns_ok () && rl78_far_
> I see. Is it correct then to say that reload will never be able to
> change a near mem into a far mem or vice versa? If that is true, there
> doesn't appear to be any real benefit to having both near and far mem
> operations as *alternatives* to the same insn pattern.
The RL78 has a segment r
> You would need some way to indicate that while Y does accept a mem,
> this particular mem can't be reloaded to match. We don't have a way
> to do that.
As a test, I added this API. It seems to work. I suppose there could
be a better API where we determine if a constrain matches various
memor
> It did match the first alternative (alternative 0), but it matched the
> constraints Y/Y/m.
It shouldn't match Y as those are for near addresses (unless it's only
matching MEM==MEM), and the ones in the insn are far, but ...
> Reload doesn't have any concept of two different kinds of memory
>
Given this test case for rl78-elf:
extern __far int a, b;
void ffr (int x)
{
a = b + x;
}
I'm trying to use this patch:
Index: gcc/config/rl78/rl78-virt.md
===
--- gcc/config/rl78/rl78-virt.md (revision 227360)
+++ gcc/confi
> If you want your commits to be attributed to two different addresses
> in the git conversion, you need to tell me how to specify two
> different selection sets so I can write assign statements and two
> trivial "authors read" commands affecting them only.
>
> assuming that the names m32c and djg
Hmmm... I use two email addresses for commits, depending on which target
they're for, i.e.:
$ grep DJ MAINTAINERS
m32c port DJ Delorie
DJGPP DJ Delorie
Most of the DJGPP stuff was long ago but I wonder how the conversion
would h
> In the mean time, I'm enclosing a contributor map that will need to be
> filled in whoever does the conversion. The right sides should become
> full names and preferred email addresses.
This information should be gleanable from the Changelog commits...
do you have a script to scan those?
I've seen this on other targets too, sometimes so bad I write a quick
target-specific "stupid move optimizer" pass to clean it up.
A generic pass would be much harder, but very useful.
> So in effect, we have two pointer sizes, 64 being the default, but
> we can also get a 32 bit pointer via the syntax above? Wow, I'm
> surprised that works.
Yup, been that way for many years.
> And the only time we'd be able to use larl is a dereference of a
> pointer declared with the syntax
In the TPF case, the software has to explicitly mark such pointers as
SImode (such things happen only when structures that contain addresses
can't change size, for backwards compatibility reasons[1]):
int * __attribute__((mode(SImode))) ptr;
ptr = &some_var;
so I wouldn't consider this the "d
Is there any reason that LARL can't be used to load a 32-bit symbolic
value, in 64-bit mode? On TPF (64-bit) the app has the option of
being loaded in the first 4Gb so that all symbols are also valid
32-bit addresses, for backward compatibility. (and if not, the linker
would complain)
Index: s3
> Did you try just a define_split instead? Ugly, but it should work I think.
It doesn't seem to be able to match a define_split :-(
Given a test case like this:
typedef struct {
unsigned char no0 :1;
unsigned char no1 :1;
unsigned char no2 :1;
unsigned char no3 :1;
unsigned char no4 :1;
unsigned char no5 :1;
unsigned char no6 :1;
unsigned char no7 :1;
} __BITS8;
#define
In this bit of code in explow.c:
/* By passing constant addresses through registers
we get a chance to cse them. */
if (! cse_not_expected && CONSTANT_P (x) && CONSTANT_ADDRESS_P (x))
x = force_reg (address_mode, x);
On the rl78 it results in code that's a bit too complex for later
Consider:
# 1 "dj.c"
# 1 "dj.h" 1 3
int dj(int x);
# 2 "dj.c" 2
int dj(int x)
{
}
If you compile with -g and look at the dwarf output, you see:
<1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
<2e> DW_AT_external: 1
<2e> DW_AT_name: dj
<31> DW_AT_decl_file : 2
In config/s390/s390.c we accept addresses that are SImode:
if (!REG_P (base)
|| (GET_MODE (base) != SImode
&& GET_MODE (base) != Pmode))
return false;
However, there doesn't seem to be anything in the s390's opcodes that
masks the top half of address registe
> This is a common problem. I guess newlib/cygwin got the oldest set
> and, afaik, the GCC toplevel stuff is kind of the master. It would
> be nice if we had some automatism in place to keep all former src
> repos in sync.
There was never any agreement on who the "master" was for toplevel
sourc
So here's what I'm trying to do... I want to build gcc, binutils, and
newlib, run tests, and IF the tests pass, THEN install them all.
However, gcc needs an installed newlib to build it's libraries.
I tried installing newlib into $DESTDIR$PREFIX but gcc ignores
$DESTDIR during the compile.
Any
> Aren't current Windows file systems case-preserving? Then they
> shouldn't have no problems with .C files.
They are case preserving, but not case sensitive. A wildcard search
for *.c will match foo.C and bar.c, and foo.c can be opened as FOO.C.
pins...@gmail.com writes:
> No because they are c++ code so capital C is correct.
However, we should avoid relying on case-sensitive file systems
(Windows) and use .cc or .cxx for C++ files ("+" is not a valid file
name character on Windows, so we can't use .c++).
> Ok, but the converse — if the general_operand is accessed by more
> than one instruction, it is not safe — is correct, right?
In general, I'd agree, but the ISO spec talks about "sequence points"
and there are times when you *can* access a volatile multiple times as
long as the state is correct
> To try to generalize from that: it looks like the operating
> principle is that an insn that expands into multiple references to a
> given operand isn’t volatile-safe, but one where there is only a
> single reference is safe?
No, if the expanded list of insns does "what the standard says, no
mo
> I looked in the documentation and didn’t see this described.
AFAIK it's not documented. Only recently was it agreed (and even
then, reluctantly) that the ISO spec could be met by such opcodes.
> One question: do you have an example of a non-volatile-safe machine so
> I can get a feel for the problems one might encounter? At best I can
> imagine a machine that optimizes "add 0, [mem]" to avoid the
> read/write, but I'm not aware of such an ISA.
For example, the MSP430 backend uses a ma
> What is involved with the auditing?
Each pattern that (directly or indirectly) uses general_operand,
memory_operand, or nonimmediate_operand needs to be checked to see if
it's volatile-safe. If so, you need to change the predicate to
something that explicitly accepts volatiles.
There's been t
Matt Godbolt writes:
> GCC's code generation uses a "load; add; store" for volatiles, instead
> of a single "add 1, [metric]".
GCC doesn't know if a target's load/add/store patterns are
volatile-safe, so it must avoid them. There are a few targets that have
been audited for volatile-safe-ness s
> However, pointer subtraction still returns ptrdiff_t, and sizeof still
> returns size_t,
Why?
If a target (rl78-elf in my case) has a named address space larger
than the generic address space (__far in my case), why is pointer math
in that named address space still truncated to sizetype?
N1275 recognizes that named address spaces might be a different size
than the generic address space, b
Last time you mentioned this, I asked what the contents of that
config.log were...
The m32c-elf with -mcpu=m32c has a word-aligned stack and uses pushes
for arguments (i.e. not accumulate_outgoing_args). In this test case,
one of the arguments is memcpy'd into place, and an assert fails:
typedef struct {
int a, b, c, d, e, f, g, h;
} foo;
int x;
void
dj (int a, int b, foo c)
> What's the next step?
Someone finds time and desire to debug it ;-)
> We see other failures in the log because newlib/targ-include
> isn't created. The rtems build include path includes that and
> needs it but it isn't created before libgcc is built. That isn't a
> problem on other targets. I don't see anything odd in the top
> configurery magic for m32c which co
I just tried a 4.9.1 build and got this error:
configure:4222: checking whether to use setjmp/longjmp exceptions
configure:: /greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/xgcc
-B/greed/dj/gnu/gcc/m32c-elf/gcc-4_9-branch/./gcc/
-B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/install/m3
> Ok, but as we are dealing exclusively with bitfields there is
> already output_constructor_bitfield which uses an intermediate
> state to "pack" bits into units that are then emitted. It shouldn't
> be hard to change that to make it pack into the appropriate bits
> instead.
That assumes that t
Revisiting an old thread, as I still want to get this feature in...
https://gcc.gnu.org/ml/gcc/2012-10/msg00099.html
> >> 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 or
> Likewise. See how global_trees is marked for example. But likely
> you forgot to mark struct int_n_trees_t to be considered for GC.
I did remember int_n_trees_t, but it seems to be working now, so who
knows what I was doing wrong :-P
Thanks!
Given this in tree.h:
struct int_n_trees_t {
tree signed_type;
tree unsigned_type;
};
extern struct int_n_trees_t int_n_trees[NUM_INT_N_ENTS];
And this in tree.c:
struct int_n_trees_t int_n_trees [NUM_INT_N_ENTS];
What is the right way to mark these for garbage collection?
I
> The "mov.L r6, r0" instruction must never be marked as frame-related, for any
> function.
Also, is that rule true if we *don't* have a frame pointer? That is,
when we add a constant to the stack to allocate the frame, should that
function be marked as frame-related? Or is it just the fp->sp
> The "mov.L r6, r0" instruction must never be marked as frame-related, for any
> function.
Is this documented somewhere?
> I gather that r0 is the stack pointer and r6 the frame pointer?
Yes.
> > 0014 0030 FDE cie= pc=..0043
> > DW_CFA_advance_loc4: 2 to 0002
> > DW_CFA_def_cfa_offset: 32
> > DW_CFA_offset: r12 at cfa-8
> > . . .
> > DW_CFA_offset: r6 at cfa-32
>
> Presumably the rx back-end and more precisely TARGET_FRAME_POINTER_REQUIRED,
> which needs to return true if cfun->calls_alloca.
The rx back-end doesn't define TARGET_FRAME_POINTER_REQUIRED, as the
documentation says the compiler handles target-independent reasons why
there needs to be a frame
While debugging some gdb-related FAILs, I discovered that gcc's
-fstack-check option effectively calls alloca() to adjust the stack
pointer.
However, it doesn't mark the stack adjustment as FRAME_RELATED even
when it's setting up the local variables for the function.
In the case of rx-elf, for t
> So far I've been testing with hardware but I'm pretty sure I read
> somewhere about an RL78 simulator, which would be a useful addition.
> Does this simulator exist, and if so, how do I run the tests against it?
The simulator is part of the GDB build.
> I tried 'make -k check RUNTESTFLAGS="-
Is there some way to get insight into which alternatives get used
during a coverage run?
The main testsuite doesn't have tests specifically to cover all the md
entries. What I meant was, I suspect it covers enough plain C test
cases to happen to use all the usual md entries.
Since each target has different md entries (both "which are used" and
"how each is used"), it would be nearly
I've thought about making a dejagnu testsuite specifically for helping
with new ports, which would mean lots of md-specific tests, but
really, the main testsuite probably covers everything you'd need to
test. All patches are supposed to be regression tested anyway, which
means running the full de
> Is it possible that the virtual pass causes inefficiencies in some
> cases by sticking with r8-r31 when one of the 'normal' registers
> would be better?
That's not a fair question to ask, since the virtual pass can *only*
use r8-r31. The first bank has to be left alone else the
devirtualizer b
This is similar to what I had to do for msp430 - I made a new
constraint that was what general_operand would have done if it allowed
volatile MEMs, and used that for instructions where a volatile's
volatileness wouldn't be broken.
> Maybe we should add a target hook/macro to control this to avoid
> duplicated code of 'general_operand' in various places?
Even in the msp430, not all patterns can be safely used with volatile
MEMs (i.e. the macro patterns). So, not all general_operand's were
replaced.
David Guillen writes:
> In any case I'm not using the restrict variable and I'm assuming
> strict is zero, this is, not checking the hard regsiters themselves.
> This is because any reg is OK for base reg. I'm pretty sure I'm
> behaving similarly to arm, cris or x86 backends.
"strict" doesn't me
> I'm curious. Have you tried out other approaches before you decided
> to go with the virtual registers?
Yes. Getting GCC to understand the "unusual" addressing modes the
RL78 uses was too much for the register allocator to handle. Even
when the addressing modes are limited to "usual" ones, G
> Ah, that certainly explains a lot. How exactly would the fixing be
> done? Is there an example I could look at for one of the other processors?
No, RL78 is the first that uses this scheme.
> I calculated a week or two ago that we could make a code-saving of
> around 8% by using near or rel
> I've managed to build GCC myself so that I could experiment a bit
> but as this is my first foray into compiler internals, I'm
> struggling to work out how things fit together and what affects
> what.
The key thing to know about the RL78 backend, is that it has two
"targets" it uses. For the f
> I presume these will be part of the headers for the library
> distributed for msp430 gcc by TI/Redhat?
I can't speak for TI's or Red Hat's plans. GNU's typical non-custom
embedded runtime is newlib/libgloss, which usually doesn't have that
much in the way of chip-specific headers or library fu
The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those). You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins as inline assembler in a common
header file:
static inli
> Repost on the patches list (with self-contained write-up, rationale for
> choices made, etc.) at the start of stage 1 for 4.10/5.0,
Ok.
> I suggest (this clearly isn't stage 3 material).
Yup. Would be nice to back port it to 4.9 later, but... understood.
Ping? Or do I need to repost on the patches list?
http://gcc.gnu.org/ml/gcc/2014-01/msg00130.html
> I don't see constants in that test.
// Test for int128 enums.
// { dg-do compile { target int128 } }
// { dg-options "" }
enum E {
e1 = 0x,
e2, e3
} e = e3;
#define SA(I,X) int a##I[(X)? 1 : -1]
SA(1, sizeof(E) == sizeof(__int128));
> Integer constant types should be tak
> I think a patch is more useful once believe feature-complete, which
> means replacing the __int128 support with the new mechanism.
One of the side-effects of taking out the existing __int128 support is
that __int128 isn't in the integer_type_kind list, so isn't a type
that is usable for constan
Ok, so I've got it checking for existing types and checking the target
for supported modes. Any other features, or is it time for a second
patch? Should I cut out the __int128 parts yet, or do you just want
to see the new code still?
To-Do: C++ parser, C++ mangling. Still no idea what to do ab
> I think using the macros for type sizes is fine, and float / vector /
> complex types are completely irrelevant to this (so standard_type_bitsize
> should maybe be standard_integer_type_bitsize).
Whew. Am I missing any in the previous code snippet (char, short,
int, long, long long) ? Those
> This seems mostly plausible, though I don't see anything to ensure that
> __intN does not exist at all if the size matches one of the standard C
> types, or if the mode fails targetm.scalar_mode_supported_p.
What do we check against for this? Is there some table of standard
types we can read
Where is the right place to set the array of "this __intN mode is
enabled" flags? I initially set it in tree.c where __int128 is set
up, but that happens *after* c_parse_init() needs the flag to set up
the RID_* keywords for them.
Alternately, should I be calling targetm.scalar_mode_supported_p(
> (For the types you do have, there's a need to define C++ name mangling.
I mentioned this before, and I don't have a good solution for it.
Both C++ and LTO need a mangled form of __intN types.
> This seems mostly plausible, though I don't see anything to ensure that
> __intN does not exist at all if the size matches one of the standard C
> types,
My thought here was that, since each __intN is specified by the
target, they'd know to only do so if it doesn't match an existing (for
that
First pass at actual code. I took the path of using a new macro in
TARGET-modes.def and having genmodes build the relevent tables. Part
of the table is created by genmodes, the rest is created at runtime.
genmodes: bitsize, mode.
runtime: signed/unsigned type trees
(eventually, flag for "tar
> In general you need to analyze each such case individually to produce a
> reasoned argument for what it should logically be doing. Given such
> analyses, maybe then you can identify particular tables of types in
> particular orders (for example) that should be set up to iterate through.
Ok,
> (more precisely, for int128_integer_type_node to cease to exist and
> for any front-end places needing it to call a function, with a type
> size that should not be a constant 128).
The complications I've seen there is, for example, when you're
iterating through types looking for a "best" type,
> Everything handling __int128 would be updated to work with a
> target-determined set of types instead.
>
> Preferably, the number of such keywords would be arbitrary (so I suppose
> there would be a single RID_INTN for them) - that seems cleaner than the
> system for address space keywords w
> If you do want types without corresponding modes, that goes back to
> having a hook to list the relevant type sizes.
Perhaps a FRACTIONAL_INT_TYPE() macro then, for when there's no
machine mode to go with it? Although I'm struggling to imagine a case
where a target would need to define a bit-s
> That would be one possibility - if the idea is to define __intN for all
> integer modes not matching a standard type (and passing
> targetm.scalar_mode_supported_p), I advise posting details of what effect
> this would have for all targets so we can see how many such types would
> get added.
> Instead of a target-independent __int128 keyword, there would be a set
> (possibly empty) of __intN keywords, determined by a target hook.
Or *-modes.def ?
> > So, given all that, is there any way to add the "target-specific
> > size_t" portion without waiting for-who-knows-how-long for the intN_t
> > and enum-size-type projects to finish? Some form of interim API that
> > we can put in, so that we can start working on finding all the
> > assumption
Given the logic in c/c-decl.c's diagnose_mismatched_decls, if a
built-in function is *also* declared in a system header (which is
common with newlib), gcc fails to mention either the builtin or the
declaration if you redeclare the function as something else.
I.e. this code:
int foo();
So, given all that, is there any way to add the "target-specific
size_t" portion without waiting for-who-knows-how-long for the intN_t
and enum-size-type projects to finish? Some form of interim API that
we can put in, so that we can start working on finding all the
assumptions about size_t, whil
> It is a deficiency that SIZE_TYPE is defined to be a string at all (and
> likewise for all the other target macros for standard typedefs including
> all those for ). Separately, it's a deficiency that these
> things are target macros rather than target hooks.
My thought was that there'd be
There are a couple of places in gcc where wierd-sized pointers are an
issue. While you can use a partial-integer mode for pointers, the
pointer *math* is still done in standard C types, which usually don't
match the modes of pointers and often result in suboptimal code.
My proposal is to allow t
The docs say to use HARD_REGNO_MODE_OK to enforce register pairs.
But reload (find_valid_class_1) rejects classes that include such
registers:
for (regno = 0; regno < FIRST_PSEUDO_REGISTER && !bad; regno++)
{
if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno)
> While I am at it, can I patch backends as well? For example
> mep/mep.c has an occurrence of tree_code_name[TREE_CODE (...
The mep change is pre-approved :-)
1 - 100 of 742 matches
Mail list logo
