gimple vs gimple_seq in 4.8 trunk
Hello All
I just merged the trunk (svn rev 187397) into the MELT branch (svn 187401)
and I of course noticed the merging of gimple_seq into gimple (dated
2012-05-03).
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00068.html
However, the type gimple_seq still appears in a lot of source files
(mostly gcc/gimple*.c & gcc/tree*.c)
Is this intended, or is this a temporary situation, and
further patches would remove all occurrences of gimple_seq everywhere?
If it is intended, I would really like (probably in coretypes.h near
the "typedef gimple gimple_seq;" line 75, or perhaps in gimple.h)
a one paragraph comment explaning when a coder should write gimple_seq and when
a coder should write just gimple.
If the goal is to get rid of gimple_seq completely, I suggest at least
adding a comment in coretypes.h about that, and I hope that other patches will
reduce the
number of gimple_seq occurrences in gcc/*.c
In other words, when is it good taste to write gimple in some GCC code,
and when is it good taste to write gimple_seq? Even if the types are
identical from the compiler (building GCC from source) point of view,
are these types identical for us?
If gimple is really identical to gimple_seq, I think we should get
rid of the gimple_seq identifier (and replace it everywhere with gimple).
Otherwise, that means that the gimple_seq name bears some (human) meaning
different of gimple. Then we should document, at least in comments, and
preferably also in gcc/doc/gimple.texi the meaning of each.
Having both identifiers gimple & gimple_seq conveying the same meaning would be
confusing, especially to plugin writers (who have less familiarity with GCC
internals
than we do).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: gimple vs gimple_seq in 4.8 trunk
Hi, On Fri, 11 May 2012, Basile Starynkevitch wrote: > However, the type gimple_seq still appears in a lot of source files > (mostly gcc/gimple*.c & gcc/tree*.c) > > Is this intended, or is this a temporary situation, and > further patches would remove all occurrences of gimple_seq everywhere? I'm personally undecided. Retaining gimple_seq would make it possible to change the implementation of sequences to something else relatively easily. Of course in the current situation uses of gimple where gimple_seq should have been used will creep in silently into the compiler, so that will become harder and harder over time anyway. But nevertheless it would be nice to not make it harder than necessary. > If it is intended, I would really like (probably in coretypes.h near the > "typedef gimple gimple_seq;" line 75, or perhaps in gimple.h) a one > paragraph comment explaning when a coder should write gimple_seq and > when a coder should write just gimple. gimple when you work with a specific statement (like looking at operands) gimple_seq when you work with a linear collection of thingies that happen to be statements (like appending a just created new statement) But yes, a comment would probably help. Ciao, Michael.
Re: gimple vs gimple_seq in 4.8 trunk
On Fri, May 11, 2012 at 02:12:32PM +0200, Michael Matz wrote:
> On Fri, 11 May 2012, Basile Starynkevitch wrote:
>
> > However, the type gimple_seq still appears in a lot of source files
> > (mostly gcc/gimple*.c & gcc/tree*.c)
> >
> > Is this intended, or is this a temporary situation, and
> > further patches would remove all occurrences of gimple_seq everywhere?
>
> I'm personally undecided. Retaining gimple_seq would make it possible to
> change the implementation of sequences to something else relatively
> easily.
Then perhaps we should better have something like
/* a single GIMPLE statement.
Take care to use the gimple type when you are thinking of a single
statement
only, e.g. to retrieve its operands. */
typedef union gimple_statement_d *gimple;
/* a sequence of GIMPLE statements.
Use the gimple_seq type when thinking of a sequence of statements.
The gimple_seq might have a different representation some day (and used to
have one).
*/
typedef union gimple_statement_d *gimple_seq;
I believe the above is more understandable than a "typedef gimple gimple_seq;"
which brings some assymetry in the code.
If coding in C++, we could have
typedef class Gimple *gimple;
typedef class GimpleSeq *gimple_qeq;
And if we coded in C++, we would dare having
class Gimple_statement_data {
//
};
class Gimple : public Gimple_statement_data {
//
}
class GimpleSeq : public Gimple_statement_data {
//
};
I really think that it is important to decide *now*
if gimple and gimple_seq are conceptually different
(and to document and comment that) or the same.
As you suggest, if we don't make a clear statement in a comment
and in documentation, things will surely degrade with time.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
MULTILIB_OPTIONS and DRIVER_SELF_SPEC
Hi,
MULTILIB_OPTIONS containing options defined in DRIVER_SELF_SPEC seemed
to be fine in GCC46 but fail in GCC47.
For example, I have:
xap.h:
#define DRIVER_SELF_SPECS \
"%{help:-v} %"%{mno-args-span-regs-and-mem:-mno-split-args}
%"%{mno-inline-block-copy-mode:-mno-block-copy}
%
"%{mpu:-mno-block-copy -mfunction-ptr-pi} %pwd:
/home/pm18/p4ws/pm18_binutils/bc/main/result/linux/intermediate/FirmwareGcc47Package/xap-local-xap
mkdir mpu
configure: creating cache ./config.cache
checking build system type... i686-pc-linux-gnu
checking host system type... xap-local-xap
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
xgcc: error: unrecognized command line option '-mpu'
What happened in GCC47 for this to occur?
Cheers,
--
PMatos
Re: TPF unwinding broken
On 05/09/12 17:15, DJ Delorie wrote: > A TPF stack frame has up to two return addresses in it. The second > one is used when the call crosses a shared object domain, where a stub > is between the two functions. The stub does not change the stack, but > it does eventually chain to the "correct" return address. > > In the TPF unwinder, a fallback handler is provided that traps these > stub addresses, updates the RA in the frame data, and returns. The > next iteration of the unwinding loop sees the "right" RA. > > However, the CFA is used to "uniquely identify" a call frame. Since > the same CFA has two RAs, it is no longer unique, and the assert in > _Unwind_RaiseException_Phase2() is triggered. > > Removing the assert makes everything work just fine, since the next > iteration of the loop finds the correct personality etc. > > In the past, the RA was used to uniquely identify the frame, which > also worked for TPF. > > Any ideas on how to work around this "bug" in the tpf-specific files? Can any of these stubs throw exceptions? What are they used for? My first reaction is to simply consider them invisible system frames and ignore them when it comes to unwinding... r~
Re: TPF unwinding broken
> Can any of these stubs throw exceptions? What are they used for? I suspect they're simple thunks. I can ask what they do. > My first reaction is to simply consider them invisible system frames > and ignore them when it comes to unwinding... That's what we're trying to do, but the CFA corresponds to the "normal" cfa but with a different (wrong) return address. The fallback handler corrects the RA and the next iteration sees the corrected frame. If the fallback handler borks the cfa by, for example, just subtracting 1 from it, will that confuse the unwinder? Or will it "just work".
Re: TPF unwinding broken
On 05/11/12 08:45, DJ Delorie wrote: > That's what we're trying to do, but the CFA corresponds to the > "normal" cfa but with a different (wrong) return address. The > fallback handler corrects the RA and the next iteration sees the > corrected frame. I think some ascii art or a pointer to a manual may be required here. I'm a bit confused as to how the fallback handler can find the correct RA but the "normal" unwind path can't. How do all these things fit on the stack? r~
Re: TPF unwinding broken
On 05/11/12 08:45, DJ Delorie wrote: > If the fallback handler borks the cfa by, for example, just > subtracting 1 from it, will that confuse the unwinder? Or will it > "just work". FYI this isn't entirely dis-similar to the solution we're currently using for mips16 stubs. See CALL_STUB_RET in libgcc/config/mips/mips16.S. r~
Re: TPF unwinding broken
> I'm a bit confused as to how the fallback handler can find the correct > RA but the "normal" unwind path can't. The fallback knows what address range corresponds to the stubs. It's "magic". > How do all these things fit on the stack? Every stack frame has room for two return addresses. The stub just load the RA from the "secondary" slot and jumps to it.
gcc-4.6-20120511 is now available
Snapshot gcc-4.6-20120511 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120511/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 187416 You'll find: gcc-4.6-20120511.tar.bz2 Complete GCC MD5=1838759e900cc2665b67aacb9ed47fac SHA1=93ab036e0c51643ca07ac84604b2fcdee0193670 Diffs from 4.6-20120504 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Maybe expand MAX_RECOG_ALTERNATIVES ?
I'm working on a DSP port whose unit reservations are very sensitive to operand signature. E.g., for an assembler mnemonic, there can be 35-50 different combinations of operand register classes, each having different impacts on latencies and function units. For assembler code generation, very few constraint alternatives are needed, but for the DFA pipeline description, many constraint alternatives could be handy. The maximum is currently 30, and the implementation of genattrtab would need surgery to accommodate more. My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so that I can use insn attributes to identify operand signatures, or should I use another approach? The advantage is (presumably) lower overhead at scheduling time--once operands are constrained, then finding the reservation comes cheaply. The disadvantage is that constrain_operands() is a pig, and adding alternatives could slow it down more than it would have cost to have heavier weight predicates in define_insn_reservation. Also, having so many constraints is unwieldy for define_insn, though I have found the editing job to be reasonable when I work full-screen with 200+ columns :-). Even if I wanted to expand MAX_RECOG_ALTERNATIVES, if no other port wants or needs them, then a patch to genattrtab.c might not be welcome. Before I spend any time on genattrtab, I'd like to know now if it has any hope of being accepted. G
CLOOG-PPL fails to build (OS X)
I am trying to build GCC 4.7.0 on OS X. I have compiled and installed (via make install) GMP, MPFR, MPC and PPL 0.11. However when I am trying to build CLOOG-PPL 0.15.11 it fails to build. During ./configure it says: checking for location of PolyLib... installed in standard location checking for PolyhedronTSort in -lpolylib64... no Can't find PolyLib. checking for Parma Polyhedral Library (PPL)... not using PPL Then during make it fails with messages starting with: source/../include/cloog/cloog.h:47:30: error: polylib/missing.h: No such file or directory and more errors following this first one. Please advise how I may work around this. Thanks.
Re: Maybe expand MAX_RECOG_ALTERNATIVES ?
On 05/11/12 16:00, Greg McGary wrote: > My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so > that I can use insn attributes to identify operand signatures, or should I use > another approach? After some exploration, I don't see that another approach is even possible. The predicates in define_insn_reservation must be statically evaluated by genattrtab, so I can't use (match_test "...") or (symbol_ref "..."), where "..." is arbitrary C code. Is it true that define_insn_reservation predicates can only use boolean expressions on (eq_attr ...), or am I missing something? G
