debugging capabilities on AIX ?
Hello, Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to evaluate GDB (6.4) debugging capabilities currently yields very unpleasant results compared to what we obtain with a GCC 3.4 based compiler (80+ extra failures out of 1800+ tests). We so far presumed that this is caused by limitations in the XCOFF/STABS debug info format more heavily exposed by the many great compiler improvements between 3.4 and 4.x. I'd appreciate feedback on general questions from these observations: Is it generally known/expected that xcoff/stabs debugging capabilities degrade when moving from 3.4 to 4.x ? If yes, how is that considered by AIX GCC developers ? (how serious the issue, is it fixable, are there plans/attempts to move to DWARF2, ...) Thanks much in advance, With Kind Regards, Olivier
Re: debugging capabilities on AIX ?
I wrote: << I'd appreciate feedback on general questions from these observations: Is it generally known/expected that xcoff/stabs debugging capabilities degrade when moving from 3.4 to 4.x ? If yes, how is that considered by AIX GCC developers ? (how serious the issue, is it fixable, are there plans/attempts to move to DWARF2, ...) >> , a number of followups were sent and I wanted to thank participants for the feedback we have received. We are now conducting further experiments and will report further as our understanding of the issues improves. Thanks for your feedback again, With Kind Regards, Olivier
EABI stack alignment for ppc
Hello, PPC EABI targets are currently configured with both BIGGEST_ALIGNMENT and PREFERRED_STACK_BOUNDARY set to 128, I believe to accomodate "a long double member within a structure or union shall start at the lowest available offset aligned on a 16byte boundary" Besides, for 32bit non-altivec targets, we have 64 for STACK_BOUNDARY. There is code in expand_main_function to force the stack pointer alignment to PREFERRED_STACK_BOUNDARY in such situations, not triggered for C like languages on those targets because FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN is not defined (maybe it should, btw). We apply this dynamic re-alignment to every subprogram with foreign convention in Ada, still, because alignment requests must always be obeyed when not to be rejected. It turns out that the current re-alignment code doesn't work for PPC. It first 'rounds' the stack pointer in place, and then resorts to allocate_dynamic_stack_space to "pick up the pieces", as the comment says. The latter triggers the 'allocate_stack' expander, which copies the back chain from the current stack pointer, which in turn retrieves garbage when the initial 'rounding' has had a real effect. One way of addressing that would be to adjust the re-alignment code so that it does not touch the stack pointer before calling allocate_dynamic_stack_space. Now, I'm a bit unclear on the meaning of the ABI statement quoted above, and on the real implications this should have in the compiler. Does it imply that a long double field *address* should always be a multiple of 16, or just that the *offset* should be such a multiple ? In the latter case, are bumping BIGGEST_ALIGNMENT and PREFERRED_STACK_BOUNDARY the only options ? Other thoughts ? Thanks in advance, Olivier
Re: EABI stack alignment for ppc
Dave Korn wrote: > > "a long double member within a structure or union shall start at the > >lowest available offset aligned on a 16byte boundary" > It only implies that the offset should be such a multiple, but since the > struct itself will have to be aligned to a multiple of 16 if any of its > members have to be aligned to a multiple of 16 (at least according to the C > language rules), it works out the same: the base address is aligned, the > offset is aligned because of the paragraph above, so the actual member > address (offset + base) is also aligned. Humm, doesn't "member has to be aligned on a multiple of X" apply to the address of the member ? My understanding was that the maximum of those member address alignment constraints have to be propagated to the aggregate to be translatable into local constraints on offsets. Actually the whole EABI paragraph reads: "Unlike the SVR4 ABI, an array, structure or union containing a long double shall start aligned on an 8 byte boundary. However, as in the SVR4 ABI, a long double member within a structure or union shall start at the lowest available offset aligned on a 16byte boundary, and the size of the structure or union with a long double member shall be a multiple of 16 bytes." What I find very surprising is that statisfying an EABI rule on long double offsets in aggregates has to translate into painful to maintain constraints on the stack pointer just contrary to one of the EABI major points (relaxing the stack pointer alignment). Thanks for your feedback, Olivier
Re: EABI stack alignment for ppc
Geoffrey Keating wrote: > BIGGEST_ALIGNMENT is 128 for a number of reasons, but > PREFERRED_STACK_BOUNDARY is 128 primarily so that code compiled with > -meabi can also be used on Linux and other SVR4 targets, and for > Altivec support. I see. Both would deserve comments, IMHO. Thanks for your feedback, Olivier
expand_main_function/PREFERRED_STACK_BOUNDARY on ppc
Hello, As mentioned in a previous discussion at http://gcc.gnu.org/ml/gcc/2005-04/msg01416.html we have troubles with the expand_main_function code to adjust the stack pointer to PREFERRED_STACK_BOUNDARY on entry points. It currently aligns the stack pointer by applying explicit operations on it and then resorts to allocate_dynamic_stack_space to "pick up the pieces", as the comment says: /* Forcibly align the stack. */ [...] /* Enlist allocate_dynamic_stack_space to pick up the pieces. */ We are using that code on an eabi ppc target to ensure PREFERRED_STACK_BOUNDARY is honored. The current code badly interacts with the ABI because the back-chain cannot be found at the address denoted by the stack pointer after the first step above if it actually affects the register. A possible way to address that is to have expand_main_function compute the distance between the current and aligned values of the stack pointer (without touching it), and resort to allocate_dynamic_stack_space to allocate exactly that amount. We have thought of slighlty updating the allocate_dynamic_stack_space interface and code for the sake of this specific interaction. I can provide more details as well as a tentative patch, and would be glad to hear opinions on the overall issue and approach first, so ... Thanks in advance for your help, Olivier
Re: expand_main_function/PREFERRED_STACK_BOUNDARY on ppc
Richard Henderson wrote: > > A possible way to address that is to have expand_main_function compute the > > distance between the current and aligned values of the stack pointer and > > resort to allocate_dynamic_stack_space to allocate exactly that amount. > Sure, if it works. OK, I'll test my current patch more extensively and followup on GCC patches. Thanks for your reply. Olivier
rationale for bss patterns in default_section_type_flags ?
Hello, Is there a rationale for the list of bss patterns matched by default_section_type_flags_1 ? << if (strcmp (name, ".bss") == 0 || strncmp (name, ".bss.", 5) == 0 || strncmp (name, ".gnu.linkonce.b.", 16) == 0 || strcmp (name, ".sbss") == 0 || strncmp (name, ".sbss.", 6) == 0 || strncmp (name, ".gnu.linkonce.sb.", 17) == 0) flags |= SECTION_BSS; >> Would matching, say, ".bss" anywhere-in or at-the-end-of name be appropriate ? If no, why not ? Thanks in advance for your help. Olivier
Support for the MPC5554 in gcc ?
Hello, Can GCC 4.X be used to generate code running properly on a MPC5554 processor ? >From the current sources, it seems to me that the closest explicitly supported CPU is the 8540, but I'm a bit unclear if code for the latter would be fully compatible for the former, or if other variants would be better candidates. What are the GCC 3.4 capabilities on the same account ? Thanks much in advance for your help. With Kind Regards, Olivier
zero sized initializers with side effects discarded
Hello, In a number of places, the gimplifier simply discards what involves zero sized entities. For instance: in "gimplify_init_ctor_eval"... FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value) ... if (zero_sized_field_decl (purpose)) continue; or in "gimplify_modify_expr"... /* For zero sized types only gimplify the left hand side and right hand side as statements and throw away the assignment. */ if (zero_sized_type (TREE_TYPE (*from_p))) ... This is causing troubles when side effects are so discarded, for instance a call to a function returning a zero sized type. I have been experimenting with a simple patch adding side effects checks to the conditions, like "! TREE_SIDE_EFFECTS (value)" in init_ctor_eval and "! TREE_SIDE_EFFECTS (*from_p)" in modify_expr. The first programs in which I've observed problems were in Ada, and the patch helped them. Manual testing for C was not as successful (expected calls still missing), due to differences in the way TREE_SIDE_EFFECTS is set on various trees. Automated testing (make check) even triggered an ICE on zero-strct-4.c. Are the TREE_SIDE_EFFECTS checks mentioned above sensible ? I'd be happy to investigate further, provide testcases, work on extra patches, etc, and would welcome feedback first to ensure I'm searching in the right direction :) Thanks in advance for your advices, With Kind Regards, Olivier
Re: zero sized initializers with side effects discarded
Daniel Berlin wrote:
> Even if you "fixed" init_ctor_eval (modify_expr gimplifies the lhs and rhs
> and throws away the assignment), you're going to run into problems in
> the subvar machinery if you really have 0 sized field accesses with side
> effects.
>
> I'm not sure what the heck a "0 sized field access with side effects"
> does.
>
> After all, a 0 sized field has no space, etc (in fact, it is nothing), so
> how could you side-effect by accessing one, since any such access must do
> nothing?
You may have side effect from an initializer when setting a zero
sized field.
For instance (variant of gcc.c-torture/compile/zero-strct-4.c), compiled
with GCC 3.4, the code below prints "returning raw_lock" as I would
expect. It doesn't print anything when compiled with mainline because
one_raw_spinlock is not called.
#include
typedef struct {} raw_spinlock_t;
typedef struct {
raw_spinlock_t raw_lock;
} spinlock_t;
raw_spinlock_t one_raw_spinlock (void)
{
raw_spinlock_t raw_lock;
printf ("returning raw_lock\n");
return raw_lock;
}
int main(void)
{
spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
return 0;
}
Re: zero sized initializers with side effects discarded
Dave Korn wrote:
> Surely returning the vaule of this uninitialised variable makes your code
> invalid?
Well, sure. Adding an initializer in one_raw_spinlock doesn't help.
The t03.gimple dump reads:
main ()
{
struct spinlock_t D.1783;
int D.1784;
struct spinlock_t lock;
D.1784 = 0;
return D.1784;
}
Re: zero sized initializers with side effects discarded
Daniel Berlin wrote:
> > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
>
> What exactly is this code expected to do?
> Call one_raw_spinlock and then throw away the result?
Yes. As you said, the result is nothing anyway, but the function should
still be called IMO.
> If so, feel free to change gimplify_init_ctor_eval to do that.
Thanks :)
Thanks for your feedback.
Olivier
Re: zero sized initializers with side effects discarded
Andrew Pinski wrote: > > I have been experimenting with a simple patch adding side effects > > checks to the conditions, like "! TREE_SIDE_EFFECTS (value)" > > in init_ctor_eval > > Yes the one in needs to gimplify only the expression as a statement > and not add a modify statement. More on the testcase later. > You should not need the check in modify_expr as the side effects are > never mishandled as we always will add the lhs and rhs to the > instruction stream: Oh, I see - misread what it did. Thanks. I was confused by the fact that the check in init_ctor_eval did not help for C while it did for Ada. It actually doesn't change the behavior for C (at least on my testcases) because we don't get into init_ctor_eval at all, but in gimplify_expr instead, which precisely processes values with TREE_SIDE_EFFECTS set. I'm not yet clear why the call is not issued there. This is my first dive in the gimplifier, so it might well be simple. > Here is a testcase which should pass: ... It doesn't pass with the init_ctor_eval check either. > If you want me to file a bug, I can, I can also look into the issue > some too and figure out where the f++ is going to. Either is fine with me (thanks for the offer :). On my side, I will test again with only the init_ctor_eval change and submit on gcc-patches with an Ada testcase. The only regressions I had with the two changes were the ICEs on zero-strct-4.c. I don't see them with the modify_expr change removed, so hopefully the second round will go well. > Note if we change struct g to be a non zero sized struct, it works. Indeed. Thanks for your feedback. Olivier
Re: zero sized initializers with side effects discarded
Olivier Hainque wrote: > I'm not yet clear why the call is not issued there. This is my first > dive in the gimplifier, so it might well be simple. FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not set on the constructor, despite the presence of a function call in the components.
Re: Support for the MPC5554 in gcc ?
Hello, To: > Can GCC 4.X be used to generate code running properly on a MPC5554 > processor ? [...] > What are the GCC 3.4 capabilities on the same account ? David Edelsohn replied: << The base PowerPC Book-E UISA generated by GCC should work on the MPC5554. I am not sure about the difference between the 5554 e200 core and the 8540 e500 core. Kumar Gala at Freescale probably can provide more details about compatibility with GCC's e500 support and support in previous GCC releases. >> Then Clemens Koller: << I've just compiled and installed the official gcc-3.4.4 release as a native compiler on an MPC8540 like that: [...] >> and << Oh, i've just seen that: http://www.freescale.com/files/32bit/doc/white_paper/POWRPCARCPRMRM.pdf The e200z6, implemented in the MPC5556 microcontroller, is code-compatible with +e500 core (including isel, SPE, and single-precision floating-point APUs). >> This all was very useful feeback, much appreciated, thanks a lot :) With Kind Regards, Olivier
Re: zero sized initializers with side effects discarded
Andrew Pinski wrote: > > FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not > > set on the constructor, despite the presence of a function call in > > the components. > No, that is not the problem. The problem is that we gimplify the > expression for side effects but don't actually add the expression if > the gimplify put it back in the same expression. > Any ways, the following patch fixes the issue correctly. > > If you could test and post the patch, that would be nice? Will look into it as a separate change (from the init_ctor that I'm about to submit). Thanks.
Re: Aliasing violation generated by fold_builtin_memcmp?
Richard Henderson wrote: > Try > > cst_uchar_ptr_node > = build_pointer_type_for_mode (cst_uchar_node, ptr_mode, true); > > which is apparently in use by the Ada front end, but only if a > certain pragma is given. Dunno how reliably that's likely to work. We are seeing regressions in our local testsuite on cases exercising that pragma. Passing 'true' as CAN_ALIAS_ALL sets TYPE_REF_CAN_ALIAS_ALL (t), but this apparently has no influence on what tree-ssa-alias computes. Out of a preliminary look into this code (new to me), a possible place to address that appears to be 'get_tmt_for', which presumably should assign a zero alias set to tags for pointer types with that bit set. The current code doesn't do that: tree tag_type = TREE_TYPE (TREE_TYPE (ptr)); HOST_WIDE_INT tag_set = get_alias_set (tag_type); I'd be happy to work-on and submit a patch to deal with this the proper way. I'd welcome hints or directions on what the proper way should be, as I don't yet have a global view of the complete alias analysis circuitry. The 'tag alias set should be zero if ...' idea above seems logical to me. I still may well not yet see a number of other options.
Re: Aliasing violation generated by fold_builtin_memcmp?
Daniel Berlin wrote: > > Out of a preliminary look into this code (new to me), a possible > > place to address that appears to be 'get_tmt_for', which > > presumably should assign a zero alias set to tags for pointer > > types with that bit set. > Actually, you just want it to assign the same tag, not change the alias > set of every tag it assigns. Humm, and still have the corresponding alias set zero to ensure it conflicts with everything, right ? In which case almost all the bits are in already, since get_tmt_for already reuses a previously created tag if it assigned the same alias set. I tried this on a couple of testcases yesterday, and it worked fine. I am still unclear on one point: is it fine to reuse the same tag for possibly different designated types ?
Re: Aliasing violation generated by fold_builtin_memcmp?
Daniel Berlin wrote: > > I am still unclear on one point: is it fine to reuse the same tag for > > possibly different designated types ? > > Yes, as long as they have the same alias set. OK. A last detail: On the first tag_set 0 creation, we get into: if (var_ann (ptr)->type_mem_tag == NULL_TREE) tag = create_memory_tag (tag_type, true); and, if doing nothing special, trip on /* Make sure that the type tag has the same alias set as the pointed-to type. */ gcc_assert (tag_set == get_alias_set (tag)); I've relaxed the assert expression for experimentation purposes, but this is probably not the best thing to do. How would you prefer to see this addressed ?
Re: Aliasing violation generated by fold_builtin_memcmp?
Daniel Berlin wrote: > Well, doesn't the pointed-to type have set 0 because of > TYPE_REF_CAN_ALIAS_ALL (or whatever it's named :P)? Not quite: the pointer type has TYPE_REF_CAN_ALIAS_ALL, not the pointed-to type: /* Nonzero in a pointer or reference type means the data pointed to by this type can alias anything. */ #define TYPE_REF_CAN_ALIAS_ALL(NODE) \ (PTR_OR_REF_CHECK (NODE)->common.static_flag) It seems to me that get_tmt does not do the right thing today because it assigns the tag alias set from the alias set of the pointed-to type, even if CAN_ALIAS_ALL is set on the pointer type. Here is an example input tree out of an Ada testcase: sizes-gimplified public SI user align 32 symtab 0 alias set 3 sizes-gimplified public static unsigned SI ^^ user align 32 symtab 0 alias set -1> This is a pointer to integer which is declared "can actually alias anything".
SEGV in do_simple_structure_copy
Hello,
The Ada testcase below, compiled with -O2 on x86-linux, triggers a
SEGV in the current mainline compiler, there:
do_simple_structure_copy
{ ...
for (; p && p->offset < last; p = p->next)
{ ...
q = first_vi_for_offset (q, q->offset + fieldoffset);
==>temprhs.var = q->id;
Below is a description of what is going on, plus suggestions on how to
address the problem. I'd welcome feedback before submitting a patch
with all the required testing process.
The test basically constructs a record type with two 6bits long
components, each of a record type also, and the two components (called
key1 and key2) are tighly packed with a representation clause (no
hole between the two components). Something like:
6bits 6bits
|...|...|
key1key2
Eventhough the field *decls* specify a 6bits length, the *type* of
each is actually QI integer (8bits long).
The SEGV above triggers on an assignment to a .key1 component from a
standalone variable of the corresponding type. This is
Keys.One_Pair.Key1 := Keys.One_Key;
in k.adb.
Several factors come into play, AFAICS:
o the incoming 'size' argument is based on type and not decl information,
and is used to bound the iteration (to compute 'last')
o the offset increments for each component within the loop are based on
decl size information
o .key2 appears as a successor of .key1 in the lhs because they are part
of the same outer object.
We remain in the for loop after processing the assignment to .key1
because the decl size is strictly smaller than the type size, so 'last' is
not reached, and there is a 'next' variable in sight. But then, we're out
of the source standalone variable contents, so first_vi_for_offset
returns null and we SEGV on the dereference.
A very simple way to deal with this is to just 'break' out of the loop
when 'q' happens to be null, with an appropriate comment briefly
explaining how this could happen.
Another way would be to compute the incoming 'size' argument from decl
information when appropriate. This seems more involved at first sight.
Thanks in advance for your help,
Olivier
-- $ gcc -c -O2 k.adb
-- raised STORAGE_ERROR : stack overflow (or erroneous memory access)
with Keys;
procedure K is
begin
Keys.One_Pair.Key1 := Keys.One_Key;
end;
package Keys is
Key_Size : constant := 6;
type Key_Value_T is range 0 .. 2 ** Key_Size - 1;
for Key_Value_T'Size use Key_Size;
type Key_T is record
Value : Key_Value_T;
end record;
for Key_T use record
Value at 0 range 0 .. Key_Size - 1;
end record;
type Key_Pair_T is record
Key1, Key2 : Key_T;
end record;
for Key_Pair_T use record
Key1 at 0 range 0 .. Key_Size - 1;
Key2 at 0 range Key_Size .. Key_Size + Key_Size - 1;
end record;
One_Key : Key_T := (Value => 1);
One_Pair : Key_Pair_T;
end;
Re: SEGV in do_simple_structure_copy
Daniel Berlin wrote:
> IOW, you are lying to the middle-end about the size of the fields.
> Why is the type not a 6 bit integer?
Because we avoid creating a different type for every possible
bitsize, which seems to be the purpose of DECL_SIZE in the
first place and is explicitly expected by the low-level story-layout
circuitry:
layout_decl (tree decl, unsigned int known_align)
...
/* Usually the size and mode come from the data type without change,
however, the front-end may set the explicit width of the field, so its
size may not be the same as the size of its type. This happens with
bitfields, of course (an `int' bitfield may be only 2 bits, say), but it
also happens with other fields.
The C front-end behaves similarily, creating
external packed bit-field nonaddressable decl_4 QI file tt.c line 3
size
unit size
unit size
align 8 symtab 0 alias set -1
precision 3 min max >
for
typedef struct __attribute__ ((packed)) {
int x:3;
> >Another way would be to compute the incoming 'size' argument from decl
> >information when appropriate. This seems more involved at first sight.
>
> This is the correct fix, however, if you are going to lie to the
> middle end about TYPE_SIZE so that the TYPE_SIZE and DECL_SIZE do not
> match.
Well, I'm actually not sure we have a choice. And I'm not sure it is
really a lie. A restricted set of values happen to fit in a lower number
of bits than what some type allows, it is not obvious that it makes those
values of a different type.
Thanks for your feedback.
Olivier
Re: SEGV in do_simple_structure_copy
Daniel Berlin wrote: > > > > size > > > size > > precision 3 min max > > > You'll note we actually created a new type for this :) Indeed, and I think we also have that in Ada, my confusion. The TYPE_SIZE is still larger than the DECL_SIZE above, and the field really doesn't occupy a slot as large as what TYPE_SIZE says. > Thinking harder about it, you might be better off then making > everything based on TYPE_SIZE then, since we don't always have the > FIELD_DECL's handy. I'm not sure we can. I think we must have an integral mode (and size) for the type to be able to place the field on a non-byte-aligned boundary.
Re: SEGV in do_simple_structure_copy
Richard Henderson wrote: > > precision 3 min max > > ^^^ > > Actually, we did create a different type just for this bitsize. Indeed, my comment was confused on that account. > Not that that detracts from the fact that TYPE_SIZE is always a > multiple of BITS_PER_UNIT. Agreed :)
Re: SEGV in do_simple_structure_copy
Daniel Berlin wrote: > Thinking harder about it, you might be better off then making > everything based on TYPE_SIZE then, since we don't always have the > FIELD_DECL's handy. [...] > i meant in tree-ssa-structalias.c. The results you get by doing this > should be fine. Oh, OK. Will look into this. I see a couple of references to bitpos_of_field which might require a bit of care. Thanks for your feedback. Olivier
Re: Status of -fstack-usage?
Bernd Trog wrote: > Hello, Hello Bernd, > whats the status of -fstack-usage? > > Will it output the real or worst case stack usage? The latter in any case, although I'm not sure what you mean by "real" stack usage. Could you please enligthen ? Olivier
Re: Status of -fstack-usage?
Bernd Trog wrote: > By "real" I ment the actual stack usage (which is -Ox dependent) and by > "worst case" I ment by looking simply at the code before any optimization. > > The actual stack usage would be most interesting, of course. Of course, and is actually what -fstack-usage will report. I had really misinterpreted the difference you made. The reported stack usage is still a "worst case" from a run-time perspective. For instance if the static allocation in a function goes like allocate 256 in the prologue ... some code allocate 256 for whatnot reason (push arg, static alloca, ...) ... the reported stack usage is 512 eventhough only 256 are actually allocated at some points. Hope this clarifies :)
Re: Status of -fstack-usage?
Hello, Ioannis E. Venetis wrote: > Having followed this thread and searched a little bit more, I understand > that -fstack-usage will dump information into a file at compile time. Right. > However, I was wondering whether something similar would be possible at > run-time. > > I am working on multithreaded libraries and I know that many > multithreaded languages have compilers that calculate the required stack > size and pass this information on to the associated library. This way, > they can handle efficiently memory. However, this is a problem in > standalone libraries. If we could have something like: > > stack_size = __builtin_stack_size() > > that returns the maximum required stack size for , > multithreaded libraries could take advantage of it at run-time, in order > to allocate only the amount of required memory. Interesting idea :) > This is of course not a complete proposal for something, just asking if > something like that would be possible at all. Well, it depends :) Would __builtin_stack_size (F) retrieve information about F's stack frame only, or would it also recursively account for every other function that F may call ? Implementing the former is probably possible, though I'm not sure exactly how useful it would be. The latter would no doubt be much^a_lot harder.
GNU Tools Cauldron 2020
Hello, We are pleased to invite you all to the next GNU Tools Cauldron, taking place in Paris on June 12-14, 2020. As for the previous instances, we have setup a wiki page for details: https://gcc.gnu.org/wiki/cauldron2020 The conference is free to attend, registration in advance is required. To send abstracts or ask administrative questions, please email to tools-cauldron-admin AT googlegroups.com. To register, please fill out the following form: https://forms.gle/4Tocg6JnTwqyJbwq8 If unable to use this form, please visit the Wiki page above for alternative instructions on how to register. The Cauldron is organized by a group of volunteers. We are keen to add some more people so others can stand down. If you'd like to be part of that organizing committee, please email the same address. This announcement is being sent to the main mailing list of the following groups: GCC, GDB, binutils, CGEN, DejaGnu, newlib and glibc. Please feel free to share with other groups as appropriate. Best Regards, Olivier
GNU Tools Cauldron 2020 update
Dear all, With the current evolution of the COVID-19 crisis worldwide, we are unfortunately not in a position to maintain the organization of this year’s GNU Tools Cauldron as originally planned in June. We are working on the finalization of postponement options and will let everyone know as soon as everything is confirmed. We apologize for any inconvenience this might cause and ask for your understanding. If you have any concerns or questions, please do not hesitate to reach out to the committee at tools-cauldron-ad...@googlegroups.com. With Kind Regards, Olivier
Re: GNU Tools Cauldron 2020 update
Dear all, > On 19 Mar 2020, at 15:58, Olivier Hainque wrote: > > Dear all, > > With the current evolution of the COVID-19 crisis worldwide, we are > unfortunately not in a position to maintain the organization of this > year’s GNU Tools Cauldron as originally planned in June. > > We are working on the finalization of postponement options and will > let everyone know as soon as everything is confirmed. The uncertainties around the spread of COVID-19 are such that it is simply not reasonable to plan an international conference at all at this stage. It is therefore with great sadness that we announce the cancellation of the 2020 edition of the GNU Tools Cauldron :-( If you have any concerns or questions, please do not hesitate to reach out to the committee at tools-cauldron-ad...@googlegroups.com. Wishing everyone good health, Olivier
blacklisted after announce on GNU cauldron ?
Hello, Since April 14 or so, I am not receiving any more messages from the gcc or gcc-patches mailing lists. This turns out to coincide with the date I sent to multiple lists the message announcing the unfortunate cancellation of the 2020 GNU Tools Cauldron. https://gcc.gnu.org/pipermail/gcc/2020-April/232119.html I'm sorry if that was wrong somehow. I understand we're supposed not to cross post in general. That didn't seem inappropriate in this particular case. A re-subscription attempt to the gcc mailing list just failed, expectedly I guess. I'd appreciate a suggestion on how I should proceed from there. Thanks in advance, Best Regards, Olivier
Re: blacklisted after announce on GNU cauldron ?
Hi Frank, > On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote: > > Hi - > >>> A re-subscription attempt to the gcc mailing list just >>> failed, expectedly I guess. > > I see no sign in the logs of Olivier being banned in any form. Please > resubscribe online and forward complete failure symptoms if you > believe this is still happening. Thanks for your feedback! I managed to subscribe again by going through the gcc list specific info page :-) My previous attempts were issued from https://gcc.gnu.org/lists.html#subscribe Subscribing from there doesn't work and leads to a page which provides instructions which don't work either. From there I thought the coincidence was troubling. There is actually a FAQ link on the instructions page, which I just checked, and ... it directs to a 404 page: https://sourceware.org/pipermail/index.html#faqs I'll try to re-subscribe to gcc-patches now. Thanks again! With Kind Regards, Olivier
Re: blacklisted after announce on GNU cauldron ?
> On 23 Apr 2020, at 19:39, Jonathan Wakely wrote: > Patch submitted for approval now: > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html Thanks Jonathan :)
Re: condition variables on vxworks
Thanks Rasmus and Jonathan for your comments and suggestions. > On 20 May 2020, at 12:07, Jonathan Wakely wrote: > > On Wed, 20 May 2020 at 09:44, Rasmus Villemoes > wrote: >> >> Hi >> >> The condition variable implementation added in commit 806dd0472f56fd >> seems to fall into the trap(s) pointed out in the paper >> >> http://birrell.org/andrew/papers/ImplementingCVs.pdf >> >> in particular, the "if no thread is currently waiting, signal should not >> leave a full semaphore so a following _wait will just fall through". >> >> Now, libgcc/gthr.h doesn't really spell out whether __gthread condition >> variables are supposed to behave as POSIX condition variables, so I >> don't know if it's a problem in practice. > > The libstdc++ std::condition_variable assumes POSIX-ish semantics for > __gthread_cond_t. It certainly assumes that a signal/broadcast will > only wake threads that are currently waiting, not affect waits that > haven't started yet. So it seems gthr-vxworks.h should not set > __GTHREADS_CXX0X, or libstdc++ needs a different condition_variable > implementation for VxWorks. > > Libstdc++ also assumes this requirement of pthread_cond_destroy is met: > "It shall be safe to destroy an initialized condition variable upon > which no threads are currently blocked." > This means it's OK for another thread to destroy the CV after the > semTake (*cond, WAIT_FOREVER) statement in __ghtread_cond_wait, even > if the semTake (*mutex, WAIT_FOREVER) statement hasn't happened. The > code looks OK as far as that requirement goes. > I'm not sure how many other implicit assumptions libstdc++ makes about > POSIX-ish semantics. Ok. The goal was to provide an implementation suitable for libstdc++ so we'll look into this further. Thanks again for the pointers and insights on expectations! > As an aside, it looks like there are enough libgcc/config/*vx* files > to justify creating a libgcc/config/vxworks sub-directory. Indeed. I'll add this to the list :) Olivier
Re: [PATCH 0/5] some vxworks patches
Hi Rasmus, > On 26 May 2020, at 16:52, Rasmus Villemoes wrote: > > Hi Olivier et al > > I'm having quite a bit of trouble getting gcc 10 to build for our > vxworks 5 (5.5.1) target. Thanks for your message. VxWorks 5 was transitioned to End Of Life long ago so we're not testing for it any more. I have more input to convey but can't do this just now. I'll get back to you on this next week, probably through the gcc-patches list. Thanks, Olivier
Re: [PATCH 0/5] some vxworks patches
Hi Rasmus, > On 26 May 2020, at 16:52, Rasmus Villemoes wrote: > > Hi Olivier et al > > I'm having quite a bit of trouble getting gcc 10 to build for our > vxworks 5 (5.5.1) target. The first thing I hit is > > #if !defined(_WRS_VXWORKS_MAJOR) > #error "VxWorks version macros needed but not defined" > #endif > > Our version.h doesn't define that macro (however, there's a > _WRS_VXWORKS_5_X defined in vxWorks.h). Amusingly, a few of the system > headers do mention _WRS_VXWORKS_MAJOR, e.g. > > getOptLib.h:#include "vxWorks.h" /* for _WRS_VXWORKS_MAJOR, if defined. */ > > and everywhere in the headers that use that macro, they are careful to > do "#if defined (_WRS_VXWORKS_MAJOR) && (_WRS_VXWORKS_MAJOR >= 6)". > > For now, I've just monkey-patched _vxworks-versions.h to get the build > past that - I suppose what I should do is to patch our version.h > system header instead to provide those two macros. > > But most of the gthread stuff simply doesn't build against our > headers. These five patches, and a bogus definition of WIND_USR > environment variable (-mrtp doesn't make sense for us, but > vx_crtbegin-rtp.o still gets built and that fails if WIND_USR doesn't > exist) get the build a little further - I then fail to build > libstdc++, but I'd like some feedback on whether vxworks 5 is even > supposed to be (still) supported before digging further. Unfortunately, no, not really: while we don't break it intentionally, it was transitioned to End Of Life a couple of years a ago and we don't test on such configurations any more. We are gradually going to a similar path for VxWorks 6, with 6.8 EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years out. Your message comes in timely - I was about to send a note mentioning this soon now, as we are starting a transition of all our production toolchains to gcc-10 and we are resuming posting updates upstream as stage1 has just reopened. The system environment on 5 and 6 is essentially frozen. Maintaining new versions of gcc operational on such legacy versions is increasingly difficult with every release as incompatibilities of various degrees of subtlety keep creeping in. Build failures are one thing and can often be addressed, but we have witnessed, for example, issues with newer dwarf constructs incorrectly processed by the system unwind lib or wrong code gen problems on arm for vx6 related to the use of a long deprecated ABI. We can take patches that are reported as helping such cases, as we have done in the past, as long as they are localized and look generally good. But as I mentioned, we are not in a position to really test vx5 configurations any more. The series you sent seem to fit well and I'm getting to them more closely. Thanks Olivier > Rasmus Villemoes (5): > libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5 > gthr-vxworks.h: fix leftover _VXW_PRE_69 > gthr-vxworks.c: add include of taskLib.h > libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x > libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x > > libgcc/config/gthr-vxworks-cond.c | 4 > libgcc/config/gthr-vxworks-thread.c | 4 > libgcc/config/gthr-vxworks-tls.c| 5 + > libgcc/config/gthr-vxworks.c| 1 + > libgcc/config/gthr-vxworks.h| 10 +++--- > 5 files changed, 21 insertions(+), 3 deletions(-) > > -- > 2.23.0 >
Re: [PATCH 2/5] gthr-vxworks.h: fix leftover _VXW_PRE_69
> On 26 May 2020, at 16:52, Rasmus Villemoes wrote: > > _VXW_PRE_69 was introduced in 806dd0472f, then replaced by > _VXWORKS_PRE(6,9) in abb6c3eecf, but this one was missed. > > Fixes: abb6c3eecf (Introduce an internal API for VxWorks version checks) > --- > libgcc/config/gthr-vxworks.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h > index 8b55fc55407..e38174730bf 100644 > --- a/libgcc/config/gthr-vxworks.h > +++ b/libgcc/config/gthr-vxworks.h > @@ -286,7 +286,7 @@ typedef struct > typedef __gthread_tcb *__gthread_t; > > /* Typedefs specific to different vxworks versions. */ > -#if _VXW_PRE_69 > +#if _VXWORKS_PRE(6,9) > typedef int _Vx_usr_arg_t; > #define TASK_ID_NULL ((TASK_ID)NULL) > #define SEM_ID_NULL ((SEM_ID)NULL) Ok, thanks. Olivier
Re: [PATCH 0/5] some vxworks patches
Hi Rasmus, > On 04 Jun 2020, at 15:31, Rasmus Villemoes wrote: > >> Unfortunately, no, not really: while we don't break it >> intentionally, it was transitioned to End Of Life a couple >> of years a ago and we don't test on such configurations >> any more. >> >> We are gradually going to a similar path for VxWorks 6, with 6.8 >> EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years >> out. > > Hi Olivier, > > Thanks for the answer, though obviously not what I was hoping for. > Just for the record, who exactly are "we" above? AdaCore. >> We can take patches that are reported as helping such cases, >> as we have done in the past, as long as they are localized and look >> generally good. But as I mentioned, we are not in a position to >> really test vx5 configurations any more. > > I (and my customer) am willing to put in some effort to make (or keep) > gcc working for vxworks 5. Sounds good, thanks. Out of curiosity, what is your main motivation for keeping upgrading the compiler version on such an environment ? Do you have plans to move to a more recent version of VxWorks at some point ? > In case the ifdeffery in the existing > vxworks-related files becomes too unwieldy, would it be possible to > create a separate vxworks5 target, similar to the existing vxworksae > variant? A priori, I think we could do that as long as it's indeed similar to the existing vxworksae variant in terms of amount/kind of alternate sources and impact. I don't think we should go as far as entirely insulating the vx5 support. We had an issue of the exact same kind when we worked on the introduction of VxWorks7 support, and keeping things factorized helped a lot on a number of accounts. I understand the situation we're discussing is a bit different but most of the benefits remain valid I think. The changes you have so far look generally good (thanks again for proposing them!) and it seems worth pursuing a bit in this direction. I hope the changes we have in the pipe won't make it harder. The vast majority are testsuite updates and ports to other architectures. Otherwise, at a quick glance, a couple of fixincludes related bits which we might even need to revisit before upstreaming, and a minor libstdc++ configuration adjustment. They were issued with at least up to vx6 still in mind and I don't know of cases where we deliberately introduced something with the conscious knowledge that it would break older configurations. For sure, not in a fundamental impossible to recover fashion. Olivier
Re: Oliver Hainque as co-maintainer of the VxWorks port.
> On Sep 26, 2016, at 14:15 , Ramana Radhakrishnan > wrote: > > I am pleased to announce that the GCC Steering Committee has > appointed Oliver Hainque as co-maintainer for the VxWorks port. > > Please join me in congratulating Oliver on his new role. > > Oliver, please update your listing in the MAINTAINERS file. > > Thanks, > Ramana :-) Just updated the MAINTAINERS file. Thanks all!
adding support for vxworks os variants
Hello, Here is a quick description of changes we would like to contribute to the VxWorks ports, with a preliminary query to maintainers on what would be the most appropriate form for such changes to be deemed acceptable: On a few CPU families, variants of the VxWorks OS are available. Typically, there is the base VxWorks 6 or AE (653) kernel & environment, then also: - a simulator (VxSim) on some targets, - a "CERT" variant of the OS to address requirements specific to safety certification standards - a "MILS" variant of the OS to address requirements specific to security standards - an "SMP" variant of the OS for multiprocessor systems. We (AdaCore) have been maintaining toolchains for a few of these variants over the years, with integrated facilities allowing easier uses of the toolchain directly from the command line. For mils, the set of changes is significant enough to warrant a specific triplet. I'll be posting the patches soon. For the other variants, the need for separate triplets is less clear. Indeed, what the changes do is essentially to control link time behavior, typically: - for VXSIM or SMP, the crt files and libraries we need to link with are located in a different directory - for CERT, the system entry points available to the application are all in a big object and we're not supposed to link in anything else by default The WindRiver environment drives everything through a GUI and Makefiles. E.g. for CERT, this explicitly links with -nostdlib to remove all the defaults, then add what is really needed/allowed. Working directly from the command line is often useful, and doing the correct thing (getting rid of inappropriate defaults, figuring out the correct of -Ls, ...) is cumbersome. For vxsim or smp, having entirely separate toolchains with different triplets for so minor differences seemed overkill and impractical for users, so we have added "-vxsim" and "-vxsmp" command line options to our toolchains to help. We have done the same for the cert variants, with a "-vxcert" command line option, but wonder if a separate triplet wouldn't actually be better in this case. One small concern is that the system toolchains don't know about the new options, and we think that it might be of interest to minimize the interface differences. Thoughts ? Thanks in advance for your feedback, With Kind Regards, Olivier
Re: adding support for vxworks os variants
On May 19, 2014, at 15:41 , Olivier Hainque wrote: > For vxsim or smp, having entirely separate toolchains with different triplets > for so minor differences seemed overkill and impractical for users, so we have > added "-vxsim" and "-vxsmp" command line options to our toolchains to help. > > We have done the same for the cert variants, with a "-vxcert" command line > option, but wonder if a separate triplet wouldn't actually be better in this > case. > > One small concern is that the system toolchains don't know about the new > options, and we think that it might be of interest to minimize the interface > differences. > > Thoughts ? One point I forgot to mention: we have considered the use of external spec files as an alternative strategy. We have started experimenting with it and don't yet have a lot of feedback on this scheme. Your opinion on this alternate option (how much more viable/flexible/acceptable it would likely be) would be most appreciated. I'm of course happy to provide extra details on what we have been doing if needed. Olivier
Re: [BUILDROBOT] Ada broken
On Oct 3, 2014, at 06:15 , Jan Hubicka wrote: >> I'm bisecting it (on powerpc64-linux, where it also shows up); it needs >> full bootstrapping every time, so will be another one to two hours. >> >> I just hope it isn't mine, that's going to be "fun" to debug :-) > > Nono, it is mine - the devirt type picks up variadic ada type and gets > confused. I am debugging where it happens (that is indeed fun) > > Honza Thanks Jan! Thanks Jan-Benedict for the heads up and Seghr for bisecting. Olivier
Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th
Hello Jakub, On Nov 3, 2014, at 10:18 , Jakub Jelinek wrote: > The trunk is scheduled to transition from Stage 1 to Stage 3 at the end > of Saturday, November 15th (use your timezone to your advantage) ... > What larger merges are still planned for GCC 5? > What else have been people working > on and can get posted for review before stage1 closes? We (AdaCore) are planning to submit a new port for inclusion. The assignment paperwork is just being finalized. There's essentially a new config directory, no core change, so should be suitable for stage 3 as well. Apart from this, we have been working on the production of standard dwarf instead of ad-hoc encodings for more Ada constructs. The first patches were submitted for review and you have provided very useful feedback already. Improvements were proposed and my understanding is that this is just pending a final round of review https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02217.html We have a few followup patches on top of this one. Would be great if we could get some of these in, and we'll be happy to submit at least the first pieces for review. I understand this will be tight though and we'll wait until the next stage1 for whatever remains. Otherwise, still pending review is a correction to fix unwinding on the e500 series of powerpc: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03264.html (this could be stage3 or even 4 IMO). Thanks a lot for your help!
Re: Obsolete powerpc*-*-*spe*
Hi Segher, > On Feb 14, 2017, at 04:07 , Segher Boessenkool > wrote: > > Hi all, > > I propose to mark powerpc*-*-*spe* as obsolete in GCC 7. This includes > the spe.h installed header file, all the __builtin_spe* intrinsics, the > -mfloat-gprs= command-line option, and the support for the SPE ABIs. > > No one has properly tested these targets in a long time (the latest > testresults I could find are from July 2015, >1000 failures), and the > SPE support makes a lot of code much more complex. > Any objections to this obsoletion? GCC 7 will then be the last release > with support for SPE (it will need --enable-obsolete to build these > targets), and we will delete the SPE support during GCC 8 development. While I understand you already know of existing users and I see the background of your move, I believe it would be a real loss. Here are a few datpoints from here: We have quite a few active users of spe based ports, some big, on both bare-metal and VxWorks configurations, including the recent VxWorks 7 series that we're planning to contribute when stage1 reopens. We are running a fair amount of tests nightly in-house, ACATS for Ada + various batches of regression tests, so keep a constant eye on the state of these ports. We are actually discussing running dejagnu testsuites as well, and we could post test results as soon as we have them. We have participated in the port maintenance in the past and are willing to keep helping as much as we can. We don't have the manpower of chip makers for new versions or extensions of course. With Kind Regards, Olivier
Re: Obsolete powerpc*-*-*spe*
Hi David, > On Feb 17, 2017, at 01:10 , David Edelsohn wrote: > > This is not a new issue. The maintainer did not suddenly resign last > week. There have been numerous efforts to reach out to the SPE > community for over a *decade*, cajoling them to step up with > maintenance for the port. I am glad that this notice of obsolescence > has focused more attention on the long-standing problem. Would there be a minimum level of commitment you'd like to get to accept leaving the port in (if not this, at least that ...) ? Thanks, Olivier
Re: Obsolete powerpc*-*-*spe*
> On 21 Feb 2017, at 17:14, David Edelsohn wrote: > > Hi, Olivier > > There are three main areas that require attention: > > 1) Regular builds of the SPE configuration and regular GCC testsuite > runs that are reported to the gcc-testsuite mailing list. > > 2) Timely reports of any regressions. > > 3) An active GCC developer who is the point of contact for the SPE > port and submits patches for the port. > > None of us within IBM are experts on the SPE port. Someone from the > SPE community is needed to help triage issues, debug problems and test > patches that may affect the SPE port. > > With evidence of pro-active involvement from an SPE developer, the > port does not have to be deprecated. The effort needs to be more that > activity at GCC release cycle boundaries or an accelerated deprecation > process will be proposed. Sure. Thanks David, Olivier
Re: Obsolete powerpc*-*-*spe*
Hello Andrew, > On Mar 13, 2017, at 19:01 , Andrew Jenner wrote: > > I volunteer to be the point of contact for the SPE port. > > Over here at CodeSourcery/Mentor Embedded, we have a strong interest in SPE > *not* being deprecated (we actively ship toolchain products with SPE > multilibs, and have customers for which these are important). We are > therefore volunteering resources (specifically, me) to maintain SPE upstream > as well. > > I am in the process of developing some patches to add VLE support upstream > (and expect to be maintainer of those once they are committed) so it would be > a good fit for me to be the SPE maintainer as well. > > We have been regularly running tests on the SPE multilibs (on our internal > branches) and they are in better shape than the test results Segher found > from 2015. We may have some (not yet upstreamed) patches that improve the > test results - I will be tracking these down and upstreaming them ASAP. I > will be expanding our regular build and test runs to cover trunk as well, and > will send test results to gcc-testsuite and report regressions. > > If there is no objection, I will submit patches tomorrow to un-obsolete SPE > and add myself to the appropriate section of the MAINTAINERS file. The other > changes will come once stage 1 opens. Thanks for volunteering! As mentioned upthread, we (AdaCore) also have a significant user base, so a strong interest in the port remaining alive and we'll be happy to keep submitting patches we might have. The perspective of seeing VLE support come in is great news :) Best Wishes, Olivier
Re: Obsolete powerpc*-*-*spe*
> On Mar 15, 2017, at 15:26 , Segher Boessenkool > wrote: > I do not think VLE can get in, not in its current shape at least. VLE > is very unlike PowerPC in many ways so it comes at a very big cost to > the port (maintenance and otherwise -- maintenance is what I care about > most). > > Since SPE and VLE only share the part of the rs6000 port that doesn't > change at all (except for a bug fix once or twice a year), and everything > else needs special cases all over the place, it seems to me it would be > best for everyone if we split the rs6000 port in two, one for SPE and VLE > and one for the rest. Both ports could then be very significantly > simplified. > > I am assuming SPE and VLE do not support AltiVec or 64-bit PowerPC, > please correct me if that is incorrect. Also, is "normal" floating > point supported at all? > > Do you (AdaCore and Mentor) think splitting the port is a good idea? That's actually an option we considered. We haven't gone very far in studying what this would entail and were still unclear on how much of a clean separation we could get without risking the introduction of (too much) instability. It seemed like avoiding code duplication (that would otherwise be a maintenance issue) might require refactoring in sensitive areas, e.g. prologue/epilogue expansion, but the perspective of getting two variants simpler to grasp on top of common code definitely sounds attractive and worth some effort. Olivier
latent issues with stack_ties on ppc ?
Hello,
A question on the stack/frame_tie circuitry for a ppc/V4_abi target, to
check about a potential remaining latent problem in this area.
With gcc 4.3, we had a case where the prologue generation emitted
a sequence like
(insn 191 190 192 9 t.adb:30:8 (set (reg:SI 25 25)
(mem/c:SI (plus:SI (reg:SI 11 11)
(const_int -28 [0xffe4])) [11 S4 A32])) -1 (nil))
...
(insn 199 198 200 9 t.adb:30:8 (set (mem/c:BLK (reg/f:SI 1 1) [11 A8])
(unspec:BLK [
(mem/c:BLK (reg/f:SI 1 1) [11 A8])
(insn 200 199 201 9 t.adb:30:8 (set (reg/f:SI 1 1)
(reg:SI 11 11)) -1 (nil))
insn 199 was a stack_tie intended to prevent the stack pointer restore from
moving prior to the register restores, which failed with sched2 moving both
the tie and the sp restore up, prior to insn 191. My understanding is that
that was allowed by the tie referencing the mem with r1 while the restores
access the frame via r11.
There were many PRs about similar issues, on ppc and other targets,
e.g. 38644, or 44199.
PR 44199 resulted in changes for powerpc, which introduced variations in a
couple of tie insertions. We can, however, still observe epilogue patterns
similar to the above one out of mainline today, e.g.
(note 54 31 55 2 NOTE_INSN_EPILOGUE_BEG)
...
(insn 58 57 59 2 (set (reg:SI 25 25)
(mem/c:SI (plus:SI (reg:SI 11 11)
(const_int -28 [0xffe4])) [6 S4 A8])) im.adb:10 -1
...
(insn 60 59 61 2 (set (mem/c:BLK (reg/f:SI 1 1) [6 A8])
(unspec:BLK [
(mem/c:BLK (reg/f:SI 1 1) [6 A8])
] 5)) im.adb:10 -1
(insn/f 61 60 62 2 (set (reg/f:SI 1 1)
(reg:SI 11 11)) im.adb:10 -1
(expr_list:REG_CFA_DEF_CFA (reg/f:SI 1 1)
(expr_list:REG_CFA_RESTORE (reg/f:SI 31 31)
(expr_list:REG_CFA_RESTORE (reg:SI 25 25)
for the Ada testcase below, at -O2 with a compiler configured for
powerpc-wrs-vxworks.
While I don't quite see what would prevent sched2 to issue the troublesome
reordering, I haven't been able to trigger it so far.
So my question is:
Is there indeed something blocking the tie/sp move up here (new since 4.3) ?
Or do we still have a latent problem in this case ?
Thanks in advance for your feedback,
Olivier
--
with Machine_Code;
function Im (X : Integer) return Integer is
S : String (1 .. X);
pragma Volatile (S);
begin
Machine_Code.Asm
("nop", Clobber => "25", Volatile => True);
return X;
end;
Re: latent issues with stack_ties on ppc ?
Olivier Hainque wrote:
> do we still have a latent problem in this case ?
I believe we do. Here is a C testcase recreating one problematic
situation artificially
char mysym;
char * volatile g;
void foo (long x)
{
char volatile s [x];
register char * volatile ptr asm("11");
asm volatile ("" : : : "25");
ptr = &mysym;
g = ptr;
}
With a recent mainline configured for powerpc-wrs-vxworks,
./cc1 t.c -O2 generates
...
addi 11,31,48
stw 0,g@l(9)
mr 1,11 <===
lwz 0,4(11)
lwz 25,-28(11) <===
mtlr 0
lwz 31,-4(11)
blr
the stack pointer restore was moved prior to the registers restore ops,
despite an attempt at preventing that (as required by the ABI) from
emit_prologue:
(note 39 24 40 2 NOTE_INSN_EPILOGUE_BEG)
(insn 40 39 41 2 (set (reg:SI 11 11)
(plus:SI (reg/f:SI 31 31)
(const_int 48 [0x30]))) t.c:11 -1
...
(insn 43 42 44 2 (set (reg:SI 25 25)
(mem/c:SI (plus:SI (reg:SI 11 11)
(const_int -28 [0xffe4])) [3 S4 A8])) t.c:11 -1
...
(insn 45 44 46 2 (set (mem/c:BLK (reg/f:SI 1 1) [3 A8]) <===
(unspec:BLK [ <===
(mem/c:BLK (reg/f:SI 1 1) [3 A8]) <===
(insn/f 46 45 47 2 (set (reg/f:SI 1 1)
(reg:SI 11 11)) t.c:11 -1
In the specific case at hand, there's no mem access dependence
established between insns 45 and 43, so both 45 and 46 are allowed to
move up.
While I see what's going on in the dependency computation here, I'm not
sure whether the correction should be in this area or if the mem accesses
are not supposed to be claimed conflicting anyway, in which case the stack
tie insn should be adjusted.
Olivier
Re: Anyone else run ACATS on ARM?
Hi Joel,
Joel Sherrill wrote:
> I can't seem to find the patch. Do you have a link?
The initial submission, with a description of the problem we were
having, is at
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00759.html
We have been using a slightly adjusted version for our gcc 4.3 based
line of products, attached.
I'm not clear on the status on mainline (whether the issue is still
present etc).
Olivier
* config/arm/arm.c (args_to_rsa_distance): New function. Distance
between the arguments and the registers save area.
(arm_get_frame_offsets): Account for this distance in the frame
pointer and registers save area offset computations. Add comments.
(arm_expand_prologue): Add comments on the ARM frame pointer
computation scheme. Count the "ip" push in the amount of space
we use to save registers past the arguments area. Tidy the circuitry
to restore IP past the frame pointer setup.
(arm_compute_initial_elimination_offset) :
Rewrite expressions along the lines of a straight common pattern.
*** ./gcc/config/arm/arm.c.ori Wed Feb 11 17:05:47 2009
--- ./gcc/config/arm/arm.c Fri Feb 13 12:23:39 2009
*** void (*arm_lang_output_object_attributes
*** 63,68
--- 63,69
/* Forward function declarations. */
static arm_stack_offsets *arm_get_frame_offsets (void);
+ static int arm_args_to_rsa_distance (void);
static void arm_add_gc_roots (void);
static int arm_gen_constant (enum rtx_code, enum machine_mode, rtx,
HOST_WIDE_INT, rtx, rtx, int, int);
*** arm_get_frame_offsets (void)
*** 11941,11946
--- 11942,11950
int saved;
HOST_WIDE_INT frame_size;
+ /* Space between the arguments and the register save areas. */
+ int args_to_rsa_distance = arm_args_to_rsa_distance ();
+
offsets = &cfun->machine->stack_offsets;
/* We need to know if we are a leaf function. Unfortunately, it
*** arm_get_frame_offsets (void)
*** 11962,11973
leaf = leaf_function_p ();
! /* Space for variadic functions. */
offsets->saved_args = current_function_pretend_args_size;
!
! /* In Thumb mode this is incorrect, but never used. */
! offsets->frame = offsets->saved_args + (frame_pointer_needed ? 4 : 0);
!
if (TARGET_32BIT)
{
unsigned int regno;
--- 11966,11976
leaf = leaf_function_p ();
! /* Offset from entry-sp to the bottommost slot of the arguments area,
! possibly including varargs saved by this function in its own frame. */
offsets->saved_args = current_function_pretend_args_size;
!
! /* Space for saved registers. */
if (TARGET_32BIT)
{
unsigned int regno;
*** arm_get_frame_offsets (void)
*** 12008,12016
saved += 16;
}
! /* Saved registers include the stack frame. */
! offsets->saved_regs = offsets->saved_args + saved;
offsets->soft_frame = offsets->saved_regs + CALLER_INTERWORKING_SLOT_SIZE;
/* A leaf function does not need any stack alignment if it has nothing
on the stack. */
if (leaf && frame_size == 0)
--- 12011,12032
saved += 16;
}
! /* Now, other from entry-sp offset computations, accounting for a possible
! whole between the saved-arguments and saved-registers areas. */
!
! /* Offset to the bottommost slot in the registers save area. */
! offsets->saved_regs = offsets->saved_args + args_to_rsa_distance + saved;
!
! /* Offset to hard frame pointer. On ARM, topmost slot in the registers
! sava area. This would be different on THUMB but is never used. */
! offsets->frame
! = (offsets->saved_args + args_to_rsa_distance
!+ (frame_pointer_needed ? 4 : 0));
!
! /* Offset to soft frame pointer, slot just above the locals area, past
! room for a possible interworking slot and alignment padding. */
offsets->soft_frame = offsets->saved_regs + CALLER_INTERWORKING_SLOT_SIZE;
+
/* A leaf function does not need any stack alignment if it has nothing
on the stack. */
if (leaf && frame_size == 0)
*** arm_get_frame_offsets (void)
*** 12025,12031
--- 12041,12051
&& (offsets->soft_frame & 7))
offsets->soft_frame += 4;
+ /* Offset to bottommost slot for local variables ... */
offsets->locals_base = offsets->soft_frame + frame_size;
+
+ /* ... and for outgoing arguments, bottom of the whole stack frame for
+ this function, hence also subject to possible alignment padding. */
offsets->outgoing_args = (offsets->locals_base
+ current_function_outgoing_args_size);
*** arm_compute_initial_elimination_offset (
*** 12058,12087
switch (from)
{
case ARG_POINTER_REGNUM:
switch (to)
{
case THUMB_HARD_FRAME_POINTER_REGNUM:
return 0;
case FR
Re: Exception Handling description
Michael Eager wrote: > I'll reverse-engineer the table unless I can find something > more descriptive than the comments in gcc or gdb. FWIW, I did a similar exercise long ago and synthesized my understanding in ada/raise-gcc.c, where the Ada personality routine is implemented. Olivier
BIGGEST_ALIGNMENT vs g++ compat test expectation on aix ?
Working on a collect2 related patch resubmission for ppc-aix, I
stumbled on regressions in the c++ series for a problem unrelated to
my change. Not sure how you'd typically deal with these, so providing
the datapoints here.
tmpdir-g++.dg-struct-layout-1/t027 and a couple of other tests failed
from constructs like
struct S2661 {
union{v16sf b[31];Tal2short c __attribute__((aligned (4)));}a;
float d;
};
struct S2661 s2661;
struct S2661 a2661[5];
info.als = __alignof__ (s2661);
if (&a2661[3] & (info.als - 1)) FAIL ...
the alignment check is up to that of v16sf (64bytes), and this
occasionaly fails because csects are "only" aligned in accordance with
rs6000.h:#define BIGGEST_ALIGNMENT 128
The discrepancy is visible straight from the assembly output
for e.g. t027_y (out of the unchanged compiler as well):
.csect .data[RW],4
^^^
.align 6
^^^
a2661:
.space 10240
Olivier
pa-hpux bootstrap failure after "post-cond-optab improvements"
Hello Paolo,
It seems to me that this piece of your r149032 change ...
* expr.c (expand_expr_real_1): Just use do_store_flag.
--- expr.c (revision 149031)
+++ expr.c (revision 149032)
@@ -9109,50 +9109,9 @@
temp = do_store_flag (exp,
modifier != EXPAND_STACK_PARM ? target : NULL_RTX,
tmode != VOIDmode ? tmode : mode);
- if (temp != 0)
- return temp;
+ gcc_assert (temp);
+ return temp;
causes bootstrap to fail on pa-hpux. The first level visible behavior is
a stop at the beginning of stage2
.../libiberty/sigsetmask.c:28:1: error: conflicting types for 'sigsetmask'
/usr/include/sys/signal.h:256:18: note: previous declaration ...
This is caused by configure missing the existing declaration because
configure:6773: checking for sigsetmask
...
conftest.c: In function 'main':
conftest.c:76:1: : in expand_expr_real_1, at expr.c:9112
This reproduces on the tiny case below:
/* err.c */
extern char asprintf ();
char (*f) () = asprintf;
int
main ()
{
return f != asprintf;
}
$ ./prev-gcc/cc1 err.c
err.c: In function 'main':
err.c:7:3: internal compiler error: in expand_expr_real_1, at expr.c:9112
we hit the newly introduced assert with do_store_flag returning 0 out of
/* We won't bother with store-flag operations involving function pointers
when function pointers must be canonicalized before comparisons. */
#ifdef HAVE_canonicalize_funcptr_for_compare
if (HAVE_canonicalize_funcptr_for_compare
&& ((TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 0))) == POINTER_TYPE
&& (TREE_CODE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 0
== FUNCTION_TYPE))
|| (TREE_CODE (TREE_TYPE (TREE_OPERAND (exp, 1))) == POINTER_TYPE
&& (TREE_CODE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 1
== FUNCTION_TYPE
return 0;
#endif
Could you please have a look ?
Thanks in advance,
Olivier
Re: pa-hpux bootstrap failure after "post-cond-optab improvements"
Paolo Bonzini wrote: > I'm reverting the expand_expr_real_1 part (the part that introduced the > assertion). I see, thanks for your prompt feedback, Olivier
Re: BIGGEST_ALIGNMENT vs g++ compat test expectation on aix ?
David Edelsohn wrote: > > .csect .data[RW],4 > > ^^^ > > .align 6 > > ^^^ > > a2661: > > .space 10240 > > The default alignment of CSECTs is 4, but using -fdata-sections should > place the object in its own CSECT with stricter alignment. Humm, it apparently doesn't: I see no difference in the generated assembly for t027_y.C. Olivier
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Hello Luke, Luke A. Guest wrote: > I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM. Thanks :-) > Any pointers would be gratefully received. I'm fairly sure I know where > to start. A few general points, jic. The first thing will be to adjust your target system.ads to have GCC_ZCX_Support := True, then use the gnatlib-zcx Makefile target, with essentially two effects: adjust your target system.ads further to switch the GCC_ZCX_Support to True as well, and arrange to build/link with the "-gcc" variants of a-exexpr.adb and raise.c. The system.ads changes control the compiler to declare eh regions, produce dwarf eh info etc. The use of -gcc variants is for the runtime library, switching to the libgcc services for exception propagations. raise-gcc.c hosts the Ada personality routine, where a number of changes will be needed I believe. There, please, I'd rather have the ARM specializations abstracted as much as possible, e.g. with new functions and alternate implementations, instead of provided as #ifdefs blocks spread within existing functions. Thanks, Olivier
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Luke A. Guest wrote:
> Well, I'm reading as much as I can regarding this, but finding it hard
> to work some things out.
That's a pretty complex and very precise machinery overall.
> I've been reading through:
> http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example
> code in C++ and Ada, but it doesn't seem to match up in some places,
> i.e. no calls into __register_frame_info() yet the libgcc_eh.so contains
> the function.
There's a variety of registration functions and some targets
don't resort to such calls at all, see unwind-dw2-fde-glibc.c.
A quick glance suggests that your arm-linux port might be using the
latter (from t-linux if I'm not mistaken, I'm not at all familiar with
the port though).
[...]
> Yup, aware of this so far.
[...]
> Yup.
> > raise-gcc.c hosts the Ada personality routine, where a number of changes
> > will be needed I believe.
>
> Also, I think tracebak.c
Sure, was just suggesting starters. You will have made good progress
when you get to traceback issues :) It's useful to have a global
idea of course.
Another aspect is the possible need for special processing to get through
signal handlers (the fallback_frame_state buisness on other targets).
The capability to raise from signal handlers is often useful in Ada, and
typically available with the base sjlj runtime.
Not clear to me if this would require anything special not already there
for arm-linux.
> is where the ARM specific routine(s) will need to go, included from
> another file tb-armlinux.c?
> I think this will be required as (if I'm right), different ARM CPU's
> have differing number of registers, and I think I read in the ARM
> docs that float regs won't need to be saved if they're not used. I
> could be wrong about this though.
While I know there are arm-eabi specifics wrt unwinding, I'm really
not familiar with the details so I'm not sure what exactly will be
needed for traceback computations.
Wouldn't tb-gcc.c "just work" (using _Unwind_Backtrace) ?
If not, ISTM we'd more need something like a tb-armeabi variant. To
be confirmed.
> > There, please, I'd rather have the ARM specializations abstracted as
> > much as possible, e.g. with new functions and alternate implementations,
> > instead of provided as #ifdefs blocks spread within existing functions.
>
> Well, I think that's possible to a point, obviously some things will
> have to go into ifdef's unfortunately (it's not Ada :D).
Sure. All I'm saying is that I'd prefer
#if ARM
void foo ()
void bar ()
#else
void foo ()
void bar ()
#endif
void dosomething ()
{
...
foo ()
...
bar ()
...
}
or alternate C files to
void dosomething ()
{
...
#if ARM
foo blob 1
#else
foo blob 2
#endif
...
#if ARM
bar blob 1
#else
bar blob 2
#endif
}
especially when that needs to be repeated in several places.
> Hopefully, I can rely on some help from you AdaCore guys?
Some, sure :) As I said we aren't familiar with the details of the ARM
EH specifics and we're not running arm-linux in-house, so ...
Now if you get something working, we can comment on the integration
scheme for the Ada specific parts.
> This is my first foray into GCC internals :/
Welcome :-D
Out of curiosity, why did you choose that particular topic (ZCX for
Ada on arm-linux) ? Does this just happen to seem of interest for
learning purposes, or is there a more specific need ?
Olivier
Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
[resending a reply sent to a private copy]
From: Olivier Hainque
To: "Luke A. Guest"
Subject: Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Date: Mon, 27 Sep 2010 15:18:59 +0200
Luke A. Guest wrote:
> > A quick glance suggests that your arm-linux port might be using the
> > latter (from t-linux if I'm not mistaken, I'm not at all familiar with
> > the port though).
>
> I can't see any mention of unwind in the the t-linux-eabi file, I'm
> probably missing something I just don't unerstand here :D
I was thinking of
config.gcc
arm*-*-linux*) # ARM GNU/Linux with ELF
...
tmake_file="${tmake_file} t-linux arm/t-arm"
^^^
then in config/t-linux
# Use unwind-dw2-fde-glibc
...
> > Wouldn't tb-gcc.c "just work" (using _Unwind_Backtrace) ?
>
> I would expect so, but again, not sure on this yet.
We'll see.
> > Out of curiosity, why did you choose that particular topic (ZCX for
> > Ada on arm-linux) ? Does this just happen to seem of interest for
> > learning purposes, or is there a more specific need ?
>
> In #Ada there are always people coming in and asking if there is an ARM
> GNAT, which we always say "sort of..." ARM CPU's aren't the fastest on
> the planet and not having EABI EH to help with this is something that
> really needs to be done imho.
[...]
I see, thanks.
Cheers,
Olivier
Re: "Ada.Exceptions.Exception_Propagation" is not a predefined library unit
Hello Luke, Luke A. Guest wrote: > Can anyone give me a pointer here? I'm totally new to this :/ > a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation" is not a > predefined library unit > a-exexpr.adb:39:06: "Ada.Exceptions (body)" depends on > "Ada.Exceptions.Exception_Propagation (body)" > a-exexpr.adb:39:06: "Ada.Exceptions.Exception_Propagation (body)" > depends on "Ada.Exceptions.Exception_Propagation (spec)" We discussed this internally a bit. The compiler is looking for the spec of Ada.Exceptions.Exception_Propagation in a separate file (which would be a-exexpr.ads) because you are trying to add a child of it. This won't work, as there is indeed no such file today because this unit is provided as a subunit of ada.exceptions (package bla is ... end; package body bla is separate;) What you probably could do instead is to define a System unit (e.g. System.GCC_Exceptions or System.Unwind_Control or ...) to hold the low level unwinder type definitions. That would allow reuse from other units, which might become of interest in the not so distant future. In case you don't already know about it, gnatmake -a is a very convenient device to experiment with alternate/extra Ada runtime units (accounts for variants in the current directory, for example). Olivier
Re: Status of -fstack-usage?
Hello Ioannis; Ioannis E. Venetis wrote: > > Would __builtin_stack_size (F) retrieve information about F's stack frame > > only, or would it also recursively account for every other function that > > F may call ? > > > > Implementing the former is probably possible, though I'm not sure > > exactly how useful it would be. > I agree that the former is probably not very useful. If a function is > set to run as a thread and it calls other functions, the stack required > for those functions should be accounted for. Probably the second option > is much more useful. Sure. It's unfortunately not really an option for complexity reasons. > I had a look here: > > http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html > > I think that the best would be __builtin_stack_size(F) to return what is > described as "dynamic" and "bounded" in the above link. I'm afraid there is a misunderstanding here. What -fstack-usage outputs for each function is information about the stack used only by the function itself. There is no relationship with what the functions it calls do. The "dynamic" qualifier states whether the function itself allocates dynamic amounts of stack, like with an "alloca (n)" and "n" a variable. The extra "bounded" qualifier states whether we know a bound for such dynamic allocations. > Except from recursive functions, what are the other cases where the > above size cannot be computed statically? Functions often call functions in other compilation units, so this almost always is a non-straightforward inter-unit computation issue to start with. This is what the accompaning -fcallgraph-info is about, together with some tool to merge the per-unit graphs and perform computations on the outcome. Then, any form of indirect call is a potentially hard source of difficulty and there are several variants of those across the languages supported in GCC. Third, functions we don't compile often come into play. And I'm probably forgetting a couple :)
Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00
Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > acats test cxg2014 hangs forever on hppa2.0w-hp-hpux11.00. > ,.,. CXG2014 ACATS 2.5 06-02-10 18:02:32 > - CXG2014 Check the accuracy of the SINH and COSH functions. >* CXG2014 sinh(1) actual: 7.49632E-01 expected: > 1.17520119364380146E+00 difference: > -4.25201193643801825E-01 max err: > 1.01932454980493402E-18. > Any Ideas ? I'm not sure about the hang. For the floating point operations, we are currently using *** gcc/config/pa/pa.h.ori Tue Mar 30 11:42:04 2004 --- gcc/config/pa/pa.h Tue Mar 30 11:45:20 2004 *** *** 461,466 --- 461,471 #define UNITS_PER_WORD (TARGET_64BIT ? 8 : 4) #define MIN_UNITS_PER_WORD 4 + /* The widest floating point format supported by the hardware. Note that +setting this influences some Ada floating point type sizes, currently +required for GNAT to operate properly. */ + #define WIDEST_HARDWARE_FP_SIZE 64 + in our GCC 3.4 based tree. I haven't yet been able to check the situation in 4.X, which is why no patch submission has been issued as of today. You might still want to give it a try, though, because I think it is likely to remain applicable. It probably incurs a difference in size between C and Ada long_double s but this is minor compared to kind of damage you are observing. Olivier
Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00
Rainer wrote: > The patch proposed by Olivier applied to 4.1 gives 0 failures for the whole > acats testsuite, John David wrote: > While not quite as good as your 4.1.0 results, I had a similar improvement > on 4.0.3: http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg00815.html Many thanks to both John David and Rainer for the testing and feedback :) John David wrote: > Olivier, with the addition of a ChangeLog entry, the patch is ok > for all active branches (3.4, 4.0, 4.1 and trunk). Understood. > Mark, is it ok for Olivier to apply the patch mentioned here on > 4.1? > http://gcc.gnu.org/ml/gcc/2006-02/msg00251.html > > It only affects Ada on PA HP-UX. It's obviously correct. I'm deferring commits until the set of branches to which I should apply is settled. Thanks again for your feedback and for exercising Ada :) Olivier
Re: hang in acats testsuite test cxg2014 on hppa2.0w-hp-hpux11.00
Mark Mitchell wrote: > > Mark, is it ok for Olivier to apply the patch mentioned here on > > 4.1? > Yes, thanks. I have been away for a couple of days and see that the patch has been committed to the various branches. Thanks :)
label formats in gcc 3.4 for arm-vxworks
Hello, Working on an arm-vxworks port for Ada, we noticed that both NO_DOT_IN_LABEL and NO_DOLLAR_IN_LABEL are defined, the former from config/vxworks.h and the latter from arm/aout.h. Is it really intended this way ? NO_DOT_IN_LABEL is actually #undef'ed from config/vxworks.h, but the arm/aout.h overrules it because tm_file="... vxworks.h arm/elf.h arm/aout.h ... arm/vxworks.h" This is causing labels for nested functions to be formatted by # define ASM_PN_FORMAT "__%s_%lu" ... causing some troubles to the debugger, which fails to reconstruct the proper user level name. Before investigating possible debugger adjustments, we wanted to check whether the compiler configuration was as intented. Thanks in advance for your help, Olivier
categorize_ctor_elements/nc_elts vs initializer_constant_valid_p
Hello all, >From a call like categorize_ctor_elements (ctor, &num_nonzero_elements, &num_nonconstant_elements, is 'num_nonconstant_elements == 0' expected to convey the same as initializer_constant_valid_p (ctor, TREE_TYPE (ctor)) ? The code in gimplify_init_constructor apparently assumes so and it is currently not true for a number of cases exposed in Ada. This results in the promotion/copy of !valip_p constructors into static storage, which triggers spurious 'invalid initial value for member' errors out of output_constructor. Thanks in advance for your help, Olivier
addressability checks in the gimplifier
Hello,
First a short description of a problem we are seeing, then a couple
of related questions on addressability checks in the gimplifier.
>From a simple Ada testcase which I can provide if need be, the front-end
is producing a MODIFY_EXPR with a lhs of the following shape when we get
to gimplify_modify_expr:
arg 1
bit offset
arg 1
in short, a variable size array_range_ref within a bitfield record component.
The lhs remains of similar shape after gimplification, the rhs is of
variable size as well, and we end up at this point in gimplify_modify_expr:
/* If we've got a variable sized assignment between two lvalues (i.e. does
not involve a call), then we can make things a bit more straightforward
by converting the assignment to memcpy or memset. */
if (TREE_CODE (*from_p) == WITH_SIZE_EXPR)
{
tree from = TREE_OPERAND (*from_p, 0);
tree size = TREE_OPERAND (*from_p, 1);
if (TREE_CODE (from) == CONSTRUCTOR)
return gimplify_modify_expr_to_memset (expr_p, size, want_value);
if (is_gimple_addressable (from))
{
*from_p = from;
return gimplify_modify_expr_to_memcpy (expr_p, size, want_value);
}
}
We get down into gimplify_modify_expr_to_memcpy, which builds ADDR_EXPRs
for both operands, which ICEs later on from expand_expr_addr_expr_1 because
the operand sketched above is not byte-aligned.
The first puzzle to me is that there is no check made that the target
is a valid argument for an ADDR_EXPR. AFAICS, it has been gimplified
with is_gimple_lvalue/fb_lvalue as the predicate/fallback pair, but
this currently doesn't imply the required properties.
I first thought that a is_gimple_addressable (*to_p) addition to the
outer condition would help, but it actually does not because the
predicate is shallow and only checks a very restricted set of
conditions (e.g. any ARRAY_RANGE_REF or COMPONENT_REF is considered
"addressable"). This is actually the reason why the gimplified lhs
tree is considered is_gimple_lvalue, from:
bool
is_gimple_lvalue (tree t)
{
return (is_gimple_addressable (t)
|| TREE_CODE (t) == WITH_SIZE_EXPR
/* These are complex lvalues, but don't have addresses, so they
go here. */
|| TREE_CODE (t) == BIT_FIELD_REF);
Assuming that the initial tree is valid GENERIC, it would seem that a more
sophisticated addressability checker (recursing down some inner refs and
checking DECL_BIT_FIELD on field decls in COMPONENT_REFs) might be required.
I'm unclear whether this could/should be is_gimple_addressable, as
comments from http://gcc.gnu.org/ml/gcc/2004-07/msg01255.html indicate
that it not designed for this sort of operation.
I'm pretty sure I'm missing implicit assumptions and/or bits of design
intents in various places, so would appreciate input on the case and
puzzles described above.
Thanks very much in advance for your help,
With Kind Regards,
Olivier
Re: addressability checks in the gimplifier
Hello,
As a followup to my previous message enquiring about the intent
underlying various addressability checks in the gimplifier, attached
is an example of patch which addresses the issues we're observing.
It for instance fixes an ICE in in expand_expr_addr_expr_1 on the
testcase below:
procedure P5 is
type Long_Message is record
Data : String (1 .. 16);
end record;
type Short_Message is record
B : Boolean;
Data : String (1 .. 4);
end record;
pragma Pack (Short_Message);
procedure Process (LM : Long_Message; Size : Natural) is
SM : Short_Message;
begin
SM.Data (1 .. Size) := LM.Data (1 .. Size);
end;
begin
null;
end;
which is the one producing the tree excerpt quoted in the previous
message (for SM.Data (1 .. Size) in Process).
The patch bootstraps fine with languages="all,ada" on i686-pc-linux-gnu,
and introduces no new regression.
Regarding gimple predicates typically not recursing down trees (in
accordance with the grammar), as I said
<< I'm pretty sure I'm missing implicit assumptions and/or bits of design
intents in various places, so would appreciate input on the case and
puzzles described above.
>>
So this patch is posted here primarily for discussion purposes. I'd
welcome suggestions on better ways to address this, if the approach is
indeed considered inappropriate.
Thanks in advance for your help,
With Kind Regards,
Olivier
2006-06-19 Olivier Hainque <[EMAIL PROTECTED]>
* tree-gimple.c (is_gimple_lvalue, is_gimple_addressable): Account for
possibly nested bitfield component refs, not addressable while still
valid lvalues.
*** tree-gimple.c.ori Tue May 30 15:55:07 2006
--- tree-gimple.c Mon Jun 19 16:50:38 2006
*** rhs_predicate_for (tree lhs)
*** 139,149
bool
is_gimple_lvalue (tree t)
{
! return (is_gimple_addressable (t)
! || TREE_CODE (t) == WITH_SIZE_EXPR
! /* These are complex lvalues, but don't have addresses, so they
!go here. */
! || TREE_CODE (t) == BIT_FIELD_REF);
}
/* Return true if T is a GIMPLE condition. */
--- 139,148
bool
is_gimple_lvalue (tree t)
{
! return (TREE_CODE (t) == WITH_SIZE_EXPR
! || INDIRECT_REF_P (t)
! || handled_component_p (t)
! || is_gimple_variable (t));
}
/* Return true if T is a GIMPLE condition. */
*** is_gimple_condexpr (tree t)
*** 159,166
bool
is_gimple_addressable (tree t)
{
! return (is_gimple_id (t) || handled_component_p (t)
! || INDIRECT_REF_P (t));
}
/* Return true if T is function invariant. Or rather a restricted
--- 158,181
bool
is_gimple_addressable (tree t)
{
! if (is_gimple_id (t) || INDIRECT_REF_P (t))
! return true;
!
! switch (TREE_CODE (t))
! {
! case COMPONENT_REF:
! return
! !DECL_BIT_FIELD (TREE_OPERAND (t, 1))
! && is_gimple_addressable (TREE_OPERAND (t, 0));
!
! case VIEW_CONVERT_EXPR:
! case ARRAY_REF: case ARRAY_RANGE_REF:
! case REALPART_EXPR: case IMAGPART_EXPR:
! return is_gimple_addressable (TREE_OPERAND (t, 0));
!
! default:
! return false;
! }
}
/* Return true if T is function invariant. Or rather a restricted
*** gimplify.c.ori Tue May 30 15:54:59 2006
--- gimplify.c Mon Jun 19 16:55:00 2006
*** gimplify_modify_expr (tree *expr_p, tree
*** 3422,3430
return ret;
/* If we've got a variable sized assignment between two lvalues (i.e. does
! not involve a call), then we can make things a bit more straightforward
! by converting the assignment to memcpy or memset. */
! if (TREE_CODE (*from_p) == WITH_SIZE_EXPR)
{
tree from = TREE_OPERAND (*from_p, 0);
tree size = TREE_OPERAND (*from_p, 1);
--- 3422,3431
return ret;
/* If we've got a variable sized assignment between two lvalues (i.e. does
! not involve a call), we can make things a bit more straightforward by
! converting the assignment to memcpy or memset as soon as both operands
! can have their address taken. */
! if (TREE_CODE (*from_p) == WITH_SIZE_EXPR && is_gimple_addressable (*to_p))
{
tree from = TREE_OPERAND (*from_p, 0);
tree size = TREE_OPERAND (*from_p, 1);
collect2 on AIX drags too many objects from archives ?
Hello,
To address
/* The AIX linker will discard static constructors in object files if
nothing else in the file is referenced [...] */
collect2 on AIX builds the ctor/dtor tables from an explicit scan of
all the objects and libraries.
The scan actually also considers frame tables, so we end up dragging
every object with such tables even if the object is not needed at all
for other reasons.
For instance, with mainline on aix 5.3 configured with
-enable-languages=c,c++ --disable-nls --with-cpu=common, we see:
/* useless.c */
extern void nowhere ();
static void useless ()
{
nowhere ();
}
/* main.c */
int main ()
{
return 0;
}
$ g++ -c useless.cc
$ ar rv libuseless.a useless.o
ar: creating an archive file libuseless.a
a - useless.o
$ g++ -o m main.cc -L. -luseless
ld: 0711-317 ERROR: Undefined symbol: .nowhere()
...
collect2: ld returned 8 exit status
-Wl,-debug reads:
List of libraries:
./libuseless.a,
...
extern void *x7 __asm__ ("_GLOBAL__F_useless.cc__03A3E4DF");
...
static void *frame_table[] = {
&x7,
The "useless" object has been included because of a reference to its
frame tables out of collect2's processing for libuseless.a.
This behavior is problematic because it might cause the inclusion of
loads of useless objects in general, with two consequences: executables
potentially much larger than needed and unexpected dependencies.
We noticed this while working on DWARF2 exceptions support for Ada
with a static run-time library: almost the full library ends up
included in every executable, causing a significant waste in space and
forcing to systematically link with at least libm.
A possible way to address would be to perform a double scan: the
current one to discover ctors/dtors only, leaving the frame tables
alone, and a second one on the resulting executable (past a first link
phase) to discover the relevant frame tables only.
The obvious drawback is link-time performance, but since there is a
real COFF scanner and we're not using the generic "nm" based scheme,
it might not be that much of an issue. I have no hard data at hand, so
can't really tell at this point.
Thoughts ?
Thanks in advance,
Olivier
Re: collect2 on AIX drags too many objects from archives ?
Ian Lance Taylor wrote: > Why do you need the double scan? Why can't you just consistently > ignore the frame tables? Because we need the tables associated with every "useful" object to be registered for exception handling to work, and what is registered is currently what collect2 finds while it scans. It turns out the double scan actually doesn't work because the eh tables of the "useful" object linked in are garbage collected by the native linker when they are not referenced, so they are just not there when the second scan proceeds :(
Re: collect2 on AIX drags too many objects from archives ?
Mike Stump wrote: > On Sep 26, 2006, at 2:36 AM, Olivier Hainque wrote: > > /* The AIX linker will discard static constructors in object files > > if nothing else in the file is referenced [...] */ > Darwin has this same sort of issue and solves it by not wiring up > ctors/dtors for all these things but instead have a separate > convention to register/unregister the tables, both for the statically > linked things, dlopen type things and shared library type things. > Essentially, upon load, they wonder symbol tables (ok, actually the > section table) and register based upon what they find. See crt1.o > (Csu/crt.c) and keymgr/keymgr.c for additional hints. Will have a look, thanks for the pointer.
Re: PR53914, rs6000 constraints and reload queries
On Jul 17, 2012, at 17:34 , Alan Modra wrote:
> The ICE is
>
> combine.c:5318:1: error: insn does not satisfy its constraints:
> (insn 4211 1484 1493 140 (set (mem/c:DI (plus:SI (reg/f:SI 19 19 [2736])
>(const_int 32760 [0x7ff8])) [3 __gcov0.subst+816 S8 A64])
>(reg:DI 6 6)) 399 {*movdi_internal32}
> (nil))
> However, the "o" constraint rejects any offset >= 0x7ff4 due to
> rs6000_mode_dependent_address. This particular problem has been known
> for a long time, but that's not the only problem with "o" (and also
> the rs6000 "Y" constraint, a variant of "o").
Hi Alan,
I had made a proposal to help the rs6000_mode_dependent_address
issue, http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
Seems to me that the general idea is still valid:
<< a number of places in the compiler use the
mode_dependent_address_p predicate to actually check for weaker necessary
conditions
>>
Opinion on the proposal ?
Sorry not to have raised this earlier. Been off for a couple of weeks.
Olivier
Re: PR53914, rs6000 constraints and reload queries
On Aug 1, 2012, at 13:18 , Alan Modra wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01668.html.
> I like the idea.
:-)
> It is worth pursuing for code improvement we'll see
> even if we avoid the "o" constraint everywhere. For example,
> long long llo (long long *x) { return x[4095]; }
> will generate better powerpc -m32 -O2 code with your patch applied, I
> think.
OK. I guess I'll need to re-adapt it on top of your changes
and re-test.
My build/test machine for this configuration is down ATM, with
hardware maintenance required so this might have to wait a bit.
Thanks for your feedback,
Olivier
Re: PR53914, rs6000 constraints and reload queries
On Aug 1, 2012, at 16:04 , Ulrich Weigand wrote: > I've been wondering about mode_dependent_address_p myself. It currently > appears to cover two quite separate questions: > > - If I have a valid address, will it remain valid if I change its mode to > something else? > > - If I have a valid address, and change it mode (resulting in another > valid address), will the two address expressions have different > "meanings" or side effects? (E.g. an auto-increment address where > the increment depends on the mode size.) > > It seems to me that the first of those questions is rather redundant. > Instead of speculating whether the address would remain valid if the > mode were changed, code should IMO rather simply just change the > address and then check its validity in the usual way (legitimate > address etc.). Only the second question really provides any actual > *new* information ... > > See also the reload patch I recently posted to get rid of some uses > of offsettable_memref_p in favor of simply doing the change and testing > its validity afterwards: > http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01421.html I think I see and need to give this further thought ... Thanks for your feedback :-) Cheers, Olivier
Re: [RFC] Change (flatten) representation of memory references
Richard Guenther wrote: > I am mostly interested in the Ada <-> middle-end interaction, specially > where Adas requirements on the middle-end exceed that of C, and how this > is currently handled. [...] Thanks. There is indeed a lot to say/discuss on that ground and we'd certainly be very happy to set something up. We have just finished our latest round of back-end migration for all our ports (went from GCC 3.4 to GCC 4.1), which prooved a veeery good "exercise" to expose this sort of things.
reg "use" replacement vs match_dup operand ?
Hello,
(Having a great time in Ottawa :)
move_invariant_reg has this code:
/* Replace the uses we know to be dominated. It saves work for copy
propagation, and also it is necessary so that dependent invariants
are computed right. */
if (inv->def)
{
for (use = inv->def->uses; use; use = use->next)
{
*use->pos = reg;
df_insn_rescan (use->insn);
}
}
and we're observing a case where this updates only one of two
match_dup related ioperands. This is on i386-mingwin and the insn in
question is coming from this pattern:
(define_insn "allocate_stack_worker_32"
[(set (match_operand:SI 0 "register_operand" "+a")
(unspec_volatile:SI [(match_dup 0)] UNSPECV_STACK_PROBE))
(set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 0)))
(clobber (reg:CC FLAGS_REG))]
"!TARGET_64BIT && TARGET_STACK_PROBE"
"call\t___chkstk"
I think the intent is to convey that __chkstk is using eax as
an argument and is clobbering it.
Is this a valid pattern ?
FWIW, we're observing the anomaly on the Ada testcase below, which
produces
.152r.loop2_done
...
(insn 46 109 48 4 p.adb:10 (parallel [
(set (reg:SI 90)
(unspec_volatile:SI [
(reg:SI 105)
] 1))
...
when compiled by mainline with -O1.
Later on, we're observing bogus code calling __chkstk without reloading
eax with the proer value at a loop branch point:
.004t.gimple
...
D.1376 = __builtin_alloca (D.1363);
...
.s
...
movl-28(%ebp), %eax # D.1363, tmp102
addl$30, %eax#, tmp102
shrl$4, %eax #, tmp103
sall$4, %eax #, tmp104
movl%eax, -32(%ebp) # tmp104, <=== compute arg in
eax
L5:
movl%esi, %edi # ivtmp.34, J8b.7
movl%esp, -16(%ebp) # saved_stack.8, saved_stack.8
call___chkstk < allocate
leal27(%esp), %eax #, tmp91
movl%eax, %edx # tmp91, A14b.4
andl$-16, %edx #, A14b.4
testl %ebx, %ebx # l.0
jle L3 #,
movb$0, (%edx) #,* A14b.4
cmpl$1, %ebx #, l.0
je L3 #,
movl$1, %eax #, J15b.6
L4:
addl$1, %eax #, J15b.6
movb$0, -1(%edx,%eax)#,
cmpl%eax, %ebx # J15b.6, l.0
jne L4 #,
L3:
leal-1(%edi), %eax #, tmp94
imull -28(%ebp), %eax # D.1363, tmp95
addl-20(%ebp), %eax # blob.2, tmp96 < clobber eax
movl-28(%ebp), %ecx # D.1363,
movl%ecx, 8(%esp)#,
movl%edx, 4(%esp)# A14b.4,
movl%eax, (%esp) # tmp96,* saved_stack.8
call_memcpy #
movl-16(%ebp), %esp # saved_stack.8, saved_stack.8
cmpl-24(%ebp), %edi # D.1366, J8b.7
je L2 #,
addl$1, %esi #, ivtmp.34
jmp L5 #<=== branch back
here
eax clobbered
Re: reg "use" replacement vs match_dup operand ?
Olivier Hainque wrote:
> move_invariant_reg has this code:
>
> /* Replace the uses we know to be dominated.
> and we're observing a case where this updates only one of two
> match_dup related operands. This is on i386-mingwin [...]
This is causing nasty miscompilation of this very simple case:
char * volatile buf;
int size = 1024;
void foo (void)
{
int i, len = size;
for (i = 0; i < 5; i ++)
buf = __builtin_alloca (len);
}
./cc1 -O1 -fverbose-asm t.c
# GNU C (GCC) version 4.4.0 20080618 (experimental) (pentium-mingw32msv)
...
_foo:
pushl %ebp #
movl%esp, %ebp #,
pushl %edi #
pushl %esi #
pushl %ebx #
subl$12, %esp#,
movl$0, %edx #, i
movl_size, %eax # size, len
L2:
call___chkstk
leal15(%esp), %eax #, tmp68
andl$-16, %eax #, tmp70
movl%eax, _buf # tmp70, buf
addl$1, %edx #, i
cmpl$5, %edx #, i
jne L2 #,
...
The way eax is clobbered and reused as an argument to chkstk is
very, very wrong.
Re: Trouble with gdb 6.8 on Irix
Joel Brobecker wrote: > > If you care about GDB on mips-irix, I strongly advise caring about GCC as > > well, or finding someone to care about it. Right now, it is on the list > > of targets to be deprecated in GCC 4.4 because we wish to remove fixproto > > and it is one of the few targets still using fixproto (so someone would > > need to stop it from using fixproto, and make fixincludes do any necessary > > fixes fixproto does at present for this target). > I can ask Olivier or Eric if they have some time to have a look. I can have a preliminary look, though I'm not familiar with the details of what fixproto is doing exactly on this target. We still care about this target today, I still have on my list to followup on patch adjustment suggestions issued not so long ago, and I'd be happy to post the testresults we had. Olivier
refinements to definition of TREE_READONLY ?
Hello, According to comments in PR/35493, when DECL_INITIAL is null on a TREE_READONLY decl, the middle-end may assume the value to be zero. This is not explicit from the current definitions in tree.h, we'd like to understand if this is actually the case and to suggest a doc extension to this effect. We'd also like to get to an agreement on what TREE_READONLY means on a decl with non static storage, if anything at all. The kind of issues we're seeing is ... Ada front-end sets TREE_RO and DECL_INITIAL on a stack decl with initializer but never assigned later on, gimplify_decl_expr turns this into an explicit assignment, clears DECL_INITIAL and leaves TREE_RO set (creating an unexpected assignment with TREE_RO on the lhs). later middle-end passes (e.g. tree-sra) turn this into an assignment from 0 (null DECL_INITIAL). Thanks in advance for your feedback, Olivier
Re: refinements to definition of TREE_READONLY ?
Olivier Hainque wrote: [...] While we're at it, it would be nice to settle similar notions about TREE_CONSTANT. There was an exchange along similar lines at http://gcc.gnu.org/ml/gcc/2005-08/msg00686.html
Re: refinements to definition of TREE_READONLY ?
Richard Guenther wrote: > A doc extension is ok. Understood, as soon as we agree on what it should say :) > > We'd also like to get to an agreement on what TREE_READONLY means on a > > decl with non static storage, if anything at all. > > Good question... > > Ada front-end sets TREE_RO and DECL_INITIAL on a stack decl with > > initializer but never assigned later on, > > gimplify_decl_expr turns this into an explicit assignment, > > clears DECL_INITIAL and leaves TREE_RO set (creating an > > unexpected assignment with TREE_RO on the lhs). > > ... I suggest to not clear DECL_INITIAL here. Leaving an assignment with TREE_RO on the lhs ? Other options we thought of were Don't set TREE_RO on the decl if !TREE_STATIC, in gigi (we might decide it doesn't make sense and document accordingly). Clear TREE_RO in gimplify_decl_expr. We could leave DECL_INITIAL there in this case as well. > > later middle-end passes (e.g. tree-sra) turn this into an > > assignment from 0 (null DECL_INITIAL). > But in the end tree-sra shouldn't try to look at DECL_INITIAL from > non-static storage. Sorry, this part was confused on my side: the issue we had with sra was with a static rhs (global Ada constant integer), of value 1, marked TREE_RO and without DECL_INITIAL.
Re: refinements to definition of TREE_READONLY ?
Richard Guenther wrote: > > Don't set TREE_RO on the decl if !TREE_STATIC, in gigi (we might > > decide it doesn't make sense and document accordingly). > > That would work. Both doing the thing in gigi and deciding that TREE_RO only makes sense if TREE_STATIC as well ? (I have no strong feeling about it, just asking to make sure I'm getting what you meant) > > Clear TREE_RO in gimplify_decl_expr. We could leave > > DECL_INITIAL there in this case as well. > > This as well. OK. > > Sorry, this part was confused on my side: the issue we had with > > sra was with a static rhs (global Ada constant integer), of value 1, > > marked TREE_RO and without DECL_INITIAL. > > So what happened? The lhs was initialized with 0 instead of 1. > The code in tree-sra looking at DECL_INITIAL looks fine. If it's ok to assume !DECL_INITIAL is equivalent to 0, indeed. Is it really ?
Re: refinements to definition of TREE_READONLY ?
Hi Richard, Still looking into this issue. Our current understanding is that our initial bug was indirectly caused by the Ada front-end setting TREE_STATIC on a DECL_EXTERNAL constant, which it shouldn't do. The straightforward fix to that uncovered corner issues with the way we set DECL_CONTEXT in some special cases. Investigating further ... Thanks for your constructive feedback, Olivier
use of %n in genmodes.c causes trouble on Vista
Hello, genmodes.c uses the %n capabilities of printf to compute the width of pieces it outputs. This causes troubles on Windows Vista, because ... << Because of security reasons, support for the %n format specifier is disabled by default in printf and all its variants. ... the default behavior is to invoke the invalid parameter handler ... >> [http://msdn2.microsoft.com/en-us/library/ms175782%28VS.80%29.aspx] It seems to me that we could replace the uses of %n by uses of printf return values. I'm not clear whether this would be considered portable enough, however. Opinions ? Thanks in advance, Olivier
Re: use of %n in genmodes.c causes trouble on Vista
Ian Lance Taylor wrote: > What is the security issue here? I'm not seeing it. Are they > concerned that attackers will modify the print control string somehow? I don't know. We simply have observed bootstrap problems during preliminary experiments on Vista, found them to be caused by uninitialized values of "count_" in genmodes and traced this to the %n issue. We have been using a patch almost identical to what Paolo posted, and and I raised the question on gcc@ to see whether this approach was considered correct before performing a formal test-cycle and submission to gcc-patches. [...] > This deficiency is presumably only going to arise for a mingw hosted > gcc. Would it be possible for the mingw startup file to call > _set_printf_count_output? Perhaps under the control of a command line > option at link time? Maybe, I don't know either. The printf-return-value solution just looked straightforward, so that's the first option which came to mind, moderated by the potential portability question. > The return value of printf is portable (unlike the return value of > sprintf). OK, I see Paolo has committed a change along those lines already. Thanks much for your feedback, Olivier
Re: use of %n in genmodes.c causes trouble on Vista
Paolo Bonzini wrote: > * genmodes.c (tagged_printf, emit_insn_modes_h): Don't > use %n on printf. Almost identical to what we have been doing internally to circumvent the issue, Thanks. Olivier
structuring a front-end subdirectory
Hello, As part of our Ada front-end maintainership, we (AdaCore) would like to introduce a subdirectory of 'ada' where we would relocate all the files implementing the Ada-front-end/GCC interface (the "gigi" sources for the internal GNAT/GCC tree interfacing, plus the build infrastructure bits: Make*.in and config-lang.in). This would be a first step in setting up a generally clearer organization of our sources and would help us move our internal trees from cvs to svn, which we are working on these days to enhance our patch submission/integration process. In our current experimental setups, only very few and simple changes to the language independant sources are necessary (one for sure, maybe two, depending on a choice to make), not at all Ada specific so of possible use to other front-ends. Before proceeding with a formal patch submission, we would appreciate feedback on the intent first and would be very happy to provide more details if need be, so ... Comments warmly welcome, Many thanks in advance, Olivier
Re: structuring a front-end subdirectory
Hello Joseph, Joseph S. Myers wrote: > If moving files, I'd encourage moving the sources built from the libada/ > and gnattools/ toplevel directories to be physically located in those > directories (or subdirectories of them) as far as possible, as one step in > the rearrangement. > I don't however know how much dependence there might be between > these sources and the compiler sources that would make such a move > difficult. A number of these sources are indeed shared (some compiler sources are used by the library and/or some tools) and moving them is not straightforward. We are however planning to rearrange things in this area as well and much appreciate your suggestions. The set of "gcc interface" files is easier to handle and moving it would really help our transition to svn in the short term, so we decided to start there. The two changes in the common infrastructure we have are: 1) Add a new "gcc_subdir" variable in config-lang.in. When set, configure looks for a complete config-lang.in, makefile fragments (Make-lang.in), lang tree files, ... in $(srcdir)//. When not set it looks in $(srcdir)/ as usual. 2) adjust gengtype not to reflect the extra subdir in the names of the files it generates. This is probably not technically mandatory. We just thought it would be nice to leave the gt filenames untouched (only dependant on the language name). The patches are short and we would be happy to submit them if the approach is deemed acceptable. > Also note that, as described in gcc/doc/sourcebuild.texi, having > gcc/ada/Makefile.in is deprecated, so I hope the rearrangement will > eventually make it possible to eliminate this deprecated file (the only > language remaining with its own Makefile.in). We would be very happy not to have to maintain this one any more :) We're not quite there yet, unfortunately, but keep this as another target improvement in mind. > In any case, files should be moved with "svn mv" so that the history is > properly maintained. Indeed. Thanks much for your feedback, Olivier
Re: structuring a front-end subdirectory
Hello Paolo, Paolo Bonzini wrote: > Would it be possible to add a --enable-small option to libada, which > would enable compilation of the subset used by GNAT? Then, one could > make libada build twice: as a host module with --enable-small, and as a > target module without the option. Humm, maybe. We'll have to think about it when considering the other candidate structural enhancements. Thanks for the suggestion. > > 1) Add a new "gcc_subdir" variable in config-lang.in. When set, configure > > looks for a complete config-lang.in, makefile fragments > > (Make-lang.in), > > lang tree files, ... in $(srcdir)//. When not > > set it looks in $(srcdir)/ as usual. > > Could you please outline the final "look" of the filesystem? Sure. The idea for this first step is to separate the components participating in the integration with GCC. We would just create a, say, ada/gcc-interface subdirectory and move Make-lang.in # build infrastructure bits Makefile.in config-lang.in ada-tree.def # internal compiler bits ada-tree.h ada.h cuintp.c decl.c deftarg.c gigi.h lang-specs.h lang.opt misc.c targtyps.c trans.c utils.c utils2.c" there. > It would seem to me that if everything was moved to libada, this > would not be necessary anymore. > If you need this as a stopgap measure, it's fine by me but I would > like a comment in configure.ac saying that this is bound to > disappear and should not be used by other language front-ends. This really is not intended as stopgap measure. Besides our move to svn, a primary goal of the suggested change is to move this set of sources out of a more general grabbag, to clarify their specific purpose and simplify the grabbag, which in turn might make further reorgs easier. I think moving them into libada would defeat this purpose. > In this case, by the way, the gengtype changes would also be less > necessary, and I could approve the configure.ac patch myself (note that > I have not finished reviewing it, so this is not --yet-- an approval). Thanks much for your feedback, Olivier
Re: structuring a front-end subdirectory
Paolo Bonzini wrote: > > It would seem to me that if everything was moved to libada, this > > would not be necessary anymore. > Sorry, I wanted to write "everything related to the Ada RTS". Oh, I see. > Of course Gigi is not going to be moved into libada. Right :-) And even if "everything related to the Ada RTS" was moved to libada, we believe extracting gigi + gcc build bits out of the rest would still be an improvement of our sources organization. We are suggesting this first (now), because it is a much simpler step to make, we are ready for it, and it would help our maintainership. Olivier
Re: why the asymmetry in VX_CRT{BEGIN,END}_SPEC?
Hi Rasmus, > On 7 Dec 2021, at 16:09, Rasmus Villemoes wrote: > > Hi Olivier > > One thing I've been meaning to ask: Is there a reason VX_CRTBEGIN_SPEC > and VX_CRTEND_SPEC are given as > > #define VX_CRTBEGIN_SPEC "vx_crtbegin.o%s" > #define VX_CRTEND_SPEC "-l:vx_crtend.o" > > so for vx_crtbegin.o, it is gcc itself which expands the full path to > the vx_crtbegin.o file, while for vx_crtend.o, the linker is instructed > to go looking for it. I don't think there's a reason today and the patchset I'm working on uses %s consistently. Cheers, Olivier
