Re: does gcc support multiple sizes, or not?
> Sure, it would be nice if these things were pointers. At the moment, they are. > However, I will reject any patch to support these alternative > pointers in C++ until all the language issues have been resolved. At the moment, there are no language issues to resolve. The only thing people were arguing about was the semantics of casting, and I agreed to using a builtin (because a plain cast won't work anyway). Everything else, except dereferencing and "implied pointers" (i.e. passing a reference, the '&' operator, etc), works just fine without any patches, so there's nothing to reject. It would be nice if dereferencing an odd pointer worked. It would definitely require target work, and probably MI work as well. I'm assuming that "dereferencing a pointer" is well defined regardless of the size of the pointer, at least at the language level. > Since you seem to be hesitant (and, reasonably so, in my opinion!) > to work on the language-design issues for C++, The remaining problems aren't really "language issues". The major problems are in the middle-end code, like optimizers, which blindly create pointers of size POINTER_SIZE when they take the address of things. The only language issue, other than C++'s "all pointers are the same size" rule, is that the target needs to participate a little more when one takes the address of something. It already participates a little, to provide alignment information. A full implementation - which I'm not asking for at this time - would need a hook to let the target generate the "address of objects" rather than have gcc blindly create a Pmode address. For example, if you declare a variable with "far" attribute, the backend doesn't get the chance to make the SYMBOL_REF :SI (for m32c) or :DI (for tpf), and if you hack that in anyway, other parts of gcc ignore it and change it to :Pmode.
Re: does gcc support multiple sizes, or not?
DJ Delorie <[EMAIL PROTECTED]> writes: | > Good! In that case, you don't need them to be pointers at all. :-) | > | > I think you should just declare them as integer types. | | That makes initializing function pointers messy. | | Besides, they're not integers. They're pointers. I'd *like* to be | able to dereference them in some simple ways in the future; telling me | to "just use integers" is a step backwards. I'm lost. In previous message, you said # I'm not trying to dereference any of these nonstandard pointers. | Why don't I "just use assembler" or "just use C"? that defeats the | whole purpose of having a high level language. I'm not sure that reasoning will advance the issue. The points raised by Mark are very important ones. They should not be hand-waved. -- Gaby
Successful built of 4.1.1 i686-pc-linux-gnu SuSE Linux 9.2 (i586) 2.6.8-24.20-default
Utilisation des specs internes. Target: i686-pc-linux-gnu Configuré avec: ../gcc-4.1.1/configure --prefix=/users/home/anpichot/downloads/gccvishnubuild/vishnu Modèle de thread: posix version gcc 4.1.1 i686-pc-linux-gnu SuSE Linux 9.2 (i586) kernel : 2.6.8-24.20-default glibc-2.3.3-118
Re: does gcc support multiple sizes, or not?
> # I'm not trying to dereference any of these nonstandard pointers. Not *now*. I'd like to in the future.
Re: Documentation for loop infrastructure
Zdenek Dvorak wrote:
> Hello,
>
>> Apologies for the previous incomplete reply. Here's the rest of the
>> comments I had for this patch.
>
> here is the updated patch. Daniel, did you write something regarding
> the lambda framework, or should I do it?
I've attached a modified version with lambda docs.
Though i still have some questions about your version.
> + @item @code{bsi_insert_on_edge_immediate_loop}: Inserts code on edge,
> splitting
> + it if necessary. Only works on GIMPLE.
^^^
Why is this not just part of bsi_insert_on_edge_immediate, and have it
do nothing interesting if the loop structures don't exist?
> + @item It makes updating of SSA form during loop transformations simpler.
> + Without LCSSA, operations like loop unrolling may force creation of PHI
> + nodes arbitrarily far from the loop, while in LCSSA, the SSA form can be
> + updated locally. However, since we only keep real operands in LCSSA, we
> + cannot use this advantage (we could have local updating of real operands,
> + but it is not much more efficient than to use generic SSA form updating
> + for it as well; the amount of changes to SSA is the same).
I'm not sure i'd keep the commentary about this in.
We can use the advantage for real operands, we just don't.
You claim for real operands, it's not really an advantage anyway.
So either it is an advantage, or it isn't.
If it is, lose the commentary.
If it's not, lose the entire paragraph from the list of advantages.
Index: doc/loop.texi
===
--- doc/loop.texi (revision 0)
+++ doc/loop.texi (revision 0)
@@ -0,0 +1,458 @@
[EMAIL PROTECTED] Copyright (c) 2006 Free Software Foundation, Inc.
[EMAIL PROTECTED] Free Software Foundation, Inc.
[EMAIL PROTECTED] This is part of the GCC manual.
[EMAIL PROTECTED] For copying conditions, see the file gcc.texi.
+
[EMAIL PROTECTED] -
[EMAIL PROTECTED] Loop Representation
[EMAIL PROTECTED] -
+
[EMAIL PROTECTED] Loop Representation
[EMAIL PROTECTED] Analysis and Representation of Loops
+
+GCC provides extensive infrastructure for work with natural loops,
+i.e., strongly connected components of CFG with only one entry block.
+This chapter describes representation of loops in GCC, both on GIMPLE
+and in RTL, as well as the interfaces to loop-related analyses
+(induction variable analysis and number of iterations analysis).
+
[EMAIL PROTECTED]
+* Loop representation:: Representation and analysis of loops.
+* Loop querying:: Getting information about loops.
+* Loop manipulation:: Loop manipulation functions.
+* LCSSA:: Loop-closed SSA form.
+* Scalar evolutions:: Induction variables on GIMPLE.
+* loop-iv:: Induction variables on RTL.
+* Number of iterations:: Number of iterations analysis.
+* Lambda:: Linear loop transformations framework.
+* Dependency analysis:: Data dependency analysis.
[EMAIL PROTECTED] menu
+
[EMAIL PROTECTED] Loop representation
[EMAIL PROTECTED] Loop representation
[EMAIL PROTECTED] Loop representation
[EMAIL PROTECTED] Loop analysis
+
+This chapter describes the representation of loops in GCC, and functions
+that can be used to build, modify and analyze this representation.
+Most of the interfaces and data structures are declared in @file{cfgloop.h}.
+At the moment, loop structures are analyzed and this information is updated
+only by the optimization passes that deal with loops, but some efforts are
+being made to make it available throughout most of the optimization passes.
+
+In general, a natural loop has one entry block (header) and possibly
+several back edges (latches) leading to the header from the inside of the loop.
+Loops with several latches may appear if several loops share a single header,
+or if there is a branching in the middle of the loop. The representation of
+loops in GCC however allows only loops with a single latch. During loop
+analysis, headers of such loops are split and forwarder blocks are created in
+order to disambiguate their structures. A heuristic based on profile
+information is used to determine whether the latches correspond to sub-loops or
+to control flow in a single loop. This means that the analysis
+sometimes changes the CFG, and if you run it in the middle of an optimization
+pass, you must be able to deal with the new blocks.
+
+Body of the loop is the set of blocks that are dominated by its header,
+and reachable from its latch against the direction of edges in CFG.
+The loops are organized in a containment hierarchy (tree) such that
+all the loops immediately contained inside loop L are the children
+of L in the tree. This tree is represented by the @code{struct
+loops} structure. The root of this tree is a fake loop that contains all blocks
+in the function. Each of the loops is represented in a @code{struct loop}
+structure. Each loop is assigne
Re: Documentation for loop infrastructure
Hello,
> >> Apologies for the previous incomplete reply. Here's the rest of the
> >> comments I had for this patch.
> >
> > here is the updated patch. Daniel, did you write something regarding
> > the lambda framework, or should I do it?
>
> I've attached a modified version with lambda docs.
>
> Though i still have some questions about your version.
> > + @item @code{bsi_insert_on_edge_immediate_loop}: Inserts code on edge,
> > splitting
> > + it if necessary. Only works on GIMPLE.
> ^^^
>
> Why is this not just part of bsi_insert_on_edge_immediate, and have it
> do nothing interesting if the loop structures don't exist?
historical reasons. I would like to clean up similar issues sometime
soon (I would prefer to say "I plan to", but given my current schedule,
it seems too optimistic :-( )
> > + @item It makes updating of SSA form during loop transformations simpler.
> > + Without LCSSA, operations like loop unrolling may force creation of PHI
> > + nodes arbitrarily far from the loop, while in LCSSA, the SSA form can be
> > + updated locally. However, since we only keep real operands in LCSSA, we
> > + cannot use this advantage (we could have local updating of real operands,
> > + but it is not much more efficient than to use generic SSA form updating
> > + for it as well; the amount of changes to SSA is the same).
>
> I'm not sure i'd keep the commentary about this in.
> We can use the advantage for real operands, we just don't.
> You claim for real operands, it's not really an advantage anyway.
Not quite (the comment is really quite complicated, but so is the
situation). Due to LCSSA, we need to make less changes to ssa form
for real operands during loop unrolling -- the changes are local.
So it would be possible to have a special-case ssa form updating code;
but since generic ssa form updating code is efficient enough, and we
would still need to run it for virtual operands, it does not make sense
to implement this special case.
This is probably not all that important, so I will consider changing the
comment. The reason I included it there is that updating SSA form
during loop unrolling is one of major reasons other compilers (LLVM, at
least) use LCSSA, and I wanted to document somewhere the reasons for why
we do not do it.
> +Once a @code{lambda_loopnest} is obtained from the conversion
> +function, it can be transformed by using
> [EMAIL PROTECTED], which takes a transformation matrix
> +to apply. Note that it is up to the caller to verify that the
> +transformation matrix is legal to apply to the loop (dependence
> +respecting, etc).
It might be good to mention lambda_transform_legal_p function here.
Zdenek
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: > At the moment, there are no language issues to resolve. No, rather, at the moment there is a class of programs which are accidentally accepted by the C++ front end and happen to do some of the things that you want. That is different from saying that the compiler supports the feature that you want. This is an undocumented extension. Note that the documentation for the mode attribute says: "This in effect lets you request an integer or floating point type according to its width." (It does not say pointer type.) It then goes on to say "and `pointer' or `__pointer__' for the mode used to represent pointers". The use of the definite article indicates that there is in fact only one mode for pointers. > The remaining problems aren't really "language issues". I'm surprised that you believe this, in view of the concrete examples I've given. I'm not sure how to convince you that there's anything non-trivial to do here, but there is. So, unfortunately, I'm stuck: all I can do is tell you that the fact that this current works at all in C++ is an accident, might go away at any point, and probably violates various assumptions in the front end. If you're willing to use integers, you'll have an easy time. If you want the more elegant language semantics of multiple pointer sizes, you'll have to take the time to read through the C++ standard and think about all the potential impact of the extension you're proposing. Or, you can decide to work on the middle end issues, try to get your patches accepted, and then come back to the front end issues later. I don't have any plans to aggressively go reject this code in the C++ front end, but I would vaguely like to clean up and specify how attributes interact with C++ in more detail, and that might result in problems for this usage. (We really need to specify how attributes interact with same-typed-ness, implicit conversions, etc.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 17, 2006 at 07:35:58AM -0700, Mark Mitchell wrote: > If you're willing to use integers, you'll have an easy time. If you > want the more elegant language semantics of multiple pointer sizes, > you'll have to take the time to read through the C++ standard and think > about all the potential impact of the extension you're proposing. Or, > you can decide to work on the middle end issues, try to get your patches > accepted, and then come back to the front end issues later. May I jog your memory about "named address spaces". Are "near" and "far" pointers something that might be able to be shoehorned into any [future] infrastructure for supporting these named address spaces? Same for DJ's oddball pointers - could they fit? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/ iD8DBQFE5IYnwyMv24BBd/gRAgJ1AJ9IVFM7cmRZy4G71F+ZIvqSr9l0ogCfZn2f +6MHu9ROUo9RKj14Rew0W4U= =ChKv -END PGP SIGNATURE-
Re: does gcc support multiple sizes, or not?
Bernd Jendrissek wrote: > May I jog your memory about "named address spaces". Are "near" and > "far" pointers something that might be able to be shoehorned into any > [future] infrastructure for supporting these named address spaces? Same > for DJ's oddball pointers - could they fit? Maybe so -- but that's another can of worms from a language design point of view... -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
Mark Mitchell wrote: >I think you really have to accept that the change you want to make goes >to a relatively fundamental invariant of C++. I don't see how you can call this a realatively fundamental invariant of C++, given how various C++ implementations have supported multiple pointer sizes for much of the history of C++. Perhaps you could argue that Standard C++ made a fundamental change to the language, but I don't think so. The original STL made specific allowances for different memory models and pointer types, and this design, with it's otherwise unnecessary "pointer" and "size_type" types, was incorporated in to the standard. I think the intent of the "(T *)(U *)(T *)x == (T *)x" invariant was only to limit the standard pointer types, not make to non-standard pointer types of differt size fundamentally not C++. (Unlike, say, the fundamental changes the standard made to how templates work...) Ross Ridge
Re: Documentation for loop infrastructure
Here is the documentation for the data dependence analysis.
@node Dependency analysis
@section Data Dependency Analysis
@cindex Data Dependency Analysis
The code for the data dependence analysis can be found in
@file{tree-data-ref.c} and its interface and data structures are
described in @file{tree-data-ref.h}. The function that computes the
data dependences for all the array and pointer references for a given
loop is @code{compute_data_dependences_for_loop}. This function is
currently used by the linear loop transform and the vectorization
passes. Before calling this function, one has to allocate two
vectors: a first vector will contain the set of data references that
are contained in the analyzed loop body, and the second vector will
contain the dependence relations between the data references. Thus if
the vector of data references is of size @code{n}, the vector
containing the dependence relations will contain @code{n*n} elements.
However if the analyzed loop contains side effects, such as calls that
potentially can interfere with the data references in the current
analyzed loop, the analysis stops while scanning the loop body for
data references, and inserts a single @code{chrec_dont_know} in the
dependence relation array.
The data references are discovered in a particular order during the
scanning of the loop body: the loop body is analyzed in execution
order, and the data references of each statement are pushed at the end
of the data reference array. Two data references syntactically occur
in the program in the same order as in the array of data references.
This syntactic order is important in some classical data dependence
tests, and mapping this order to the elements of this array avoids
costly queries to the loop body representation.
The structure describing the relation between two data references is
@code{data_dependence_relation} and the shorter name for a pointer to
such a structure is @code{ddr_p}. This structure contains:
@itemize
@item a pointer to each data reference,
@item a tree node @code{are_dependent} that is set to
@code{chrec_known} if the analysis has proved that there is no
dependence between these two data references, @code{chrec_dont_know}
if the analysis was not able to determine any useful result and
potentially there could exist a dependence between these data
references, and @code{are_dependent} is set to @code{NULL_TREE} if
there exist a dependence relation between the data references, and the
description of this dependence relation is given in the
@code{subscripts}, @code{dir_vects}, and @code{dist_vects} arrays,
@item a boolean that determines whether the dependence relation can be
represented by a classical distance vector,
@item an array @code{subscripts} that contains a description of each
subscript of the data references. Given two array accesses a
subscript is the tuple composed of the access functions for a given
dimension. For example, given @code{A[f1][f2][f3]} and
@code{B[g1][g2][g3]}, there are three subscripts: @code{(f1, g1), (f2,
g2), (f3, g3)}.
@item two arrays @code{dir_vects} and @code{dist_vects} that contain
classical representations of the data dependences under the form of
direction and distance dependence vectors,
@item an array of loops @code{loop_nest} that contains the loops to
which the distance and direction vectors refer to.
@end itemize
Several functions for pretty printing the information extracted by the
data dependence analysis are available: @code{dump_ddrs} prints with a
maximum verbosity the details of a data dependence relations array,
@code{dump_dist_dir_vectors} prints only the classical distance and
direction vectors for a data dependence relations array, and
@code{dump_data_references} prints the details of the data references
contained in a data reference array.
Re: Incorrect application of loop exit heuristic?
> > > Pat Haugen <[EMAIL PROTECTED]> wrote on 08/08/2006 11:07:58 AM: > > > Jan Hubicka <[EMAIL PROTECTED]> wrote on 08/08/2006 01:04:33 AM: > > > > > The code there is basically avoiding loops with many exists to be > > > predicted to not loop at all (ie if you have 10 exits, having every > exit > > > with 10% probability is going to make 0.9^10 (roughly 30%) probability > > > that the loop will trip. > > > > > > The code is not quite correct - first it should be computing -10th > power > > > of the probability (that is close enough to division) and also it > should > > > track down number of exist conditionals executed each iteration... > > > Would be possible to benchmark the SPEC without this division for > start? > > > How many exit conditionals are executed per iteration in your loop? > > > > > > > I did a quick scan of the loop in question. There are 62 exits in the > > loop, but best I could tell, the most that would ever be seen on a single > > iteration of the loop is 9 since most the case legs end with a 'break'. > > > > Another alternative a colleague and I kicked around was something like > > applying "max(10%/num_exits, 2%)" as the probability of the exit edges. > > > > I tried the "max(10%/num_exits, 2%)" approach and reran SPEC. Got back the > degradation on perlbmk and then some (7% improvement), also saw a couple > others improve by a couple percent. If this sounds like an acceptable > approach, I can submit a patch. Hi, thepatch limiting minimal probability to 2% seems to make sense to me, so please submit it for review. It would be nice to have the code to compute maximal number of exits from loop too, but if it is really 9, we would end up with 1% (it might however make difference elsewhere). If you would feed motivated to do so, please just do ;) Otheriwse I will add it to my ever growing TODO list. Is it possible for you to send me the SPEC results? Thanks, Honza > > -Pat
Re: libstdc++ XPASS's on Darwin
On Aug 16, 2006, at 10:41 PM, Jack Howarth wrote: We have accumulated five XPASS instances in the libstdc++ testsuite on MacOS X... XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test XPASS: 23_containers/vector/resize/1.cc execution test XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) XPASS: 27_io/ios_base/storage/2.cc execution test These consistently pass on my build machine and on Apple's regress tester. Shouldn't these be changed to no longer be marked as xfail on darwin8? I don't know of a reason not to. If you have the inclination, would you like to submit patches to fix this? I don't know if I could approve them or not, otherwise I would just pre-approve them. Normally I'd just fix it myself under the obvious rule, but I can't be certain the change is obvious.
Re: Darwin -m64 results
The bug hits about 38 other test in gfortran. These include... FAIL: gfortran.dg/actual_array_constructor_1.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/assign.f90 -O3 -g (test for excess errors) [...SNIP...] Just in case, you can detect any sort of pattern from that set of tests. They all use common blocks or modules. Your best shot at this is to try to get a reduced testcase, beginning with assign.f90 (which is the shortest of these failing testcases): integer i common i assign 2000 to i 2000 continue end Try to remove the 'assign' and 'continue' lines, see if it's still broken. Try to compile without linking (gfortran -O3 -g -c assign.f90). FX
Re: libstdc++ XPASS's on Darwin
Mike,
Well, I note sure how to handle some of these testcases. For instance,
1_strings/basic_string/element_access/char/21674.cc has...
// { dg-require-debug-mode "" }
// { dg-options "-O0 -D_GLIBCXX_DEBUG" }
// { dg-do run { xfail *-*-* } }
...which I assume implies that it really should only be set to fail
on systems which use glibc. Does the xfail statement have some
boolean logic available so that we can say xfail on all systems
that aren't darwin8? 21_strings/basic_string/element_access/wchar_t/21674.cc
appears to be the same situation.
The 23_containers/vector/resize/1.cc is Radar 3884894 and can
be fixed by just deleting "// { dg-do run { xfail *-*-darwin8* } }".
The 26_numerics/cmath/c99_classification_macros_c.cc xfail can
be fixed by just deleting the "*-*-darwin*" sections. Lastly,
27_io/ios_base/storage/2.cc is Radar 3884894 (same as 1.cc) and
explicitly notes that Darwin 8 fails because malloc doesn't return
a NULL even if an allocation fails. I assume that may have been fixed
by MacOS X 10.4.7. Could you check that Radar number? I don't know
if I have access to it through my generic connect.apple.com account.
Jack
Re: libstdc++ XPASS's on Darwin
... just an obvious remark, then I leave the issue to the darwin maintainers, of course: if some, probably most, of those XPASS are because of a more recent release of the OS, and the previous ones are still widespread and supported, I'm not sure you really want to see FAILs on the latter... Up to you, anyway... Thanks, Paolo.
Re: libstdc++ XPASS's on Darwin
On Thu, Aug 17, 2006 at 08:51:04PM +0200, Paolo Carlini wrote: > ... just an obvious remark, then I leave the issue to the darwin > maintainers, of course: if some, probably most, of those XPASS are > because of a more recent release of the OS, and the previous ones are > still widespread and supported, I'm not sure you really want to see > FAILs on the latter... Can the test framework distinguish based on the OS release? Probably not with sufficient granularity, I suppose. It seems like we need something autoconf-like for the test suite: first you run a test for missing OS features or known flaws, then you use that to adjust your notion of which tests are expected to pass.
Re: Documentation for loop infrastructure
On Thu, 17 Aug 2006, Zdenek Dvorak wrote: > here is the updated patch. Hi Zdenek, some lines look a bit long, would you mind reformatting (Emacs has a nice automated mode, for example) before committing? Gerald
Re: libstdc++ XPASS's on Darwin
On Aug 17, 2006, at 11:57 AM, Joe Buck wrote: Can the test framework distinguish based on the OS release? Yes. It's a fundamental feature: set host_triplet powerpc-apple-darwin9.0.0d1 set build_triplet powerpc-apple-darwin9.0.0d1 set target_triplet powerpc-apple-darwin9.0.0d1 set target_alias powerpc-apple-darwin9.0.0d1 Just because we do *-*-darwin* most of the time doesn't mean we can't do *-*-darwin7* or other such things. Probably not with sufficient granularity, I suppose. It is turing complete, for example, we feature test the built compiler at test time to determine what features to test...
Re: libstdc++ XPASS's on Darwin
On Thu, Aug 17, 2006 at 12:26:12PM -0700, Mike Stump wrote: > On Aug 17, 2006, at 11:57 AM, Joe Buck wrote: > >Can the test framework distinguish based on the OS release? > > Yes. It's a fundamental feature: > > set host_triplet powerpc-apple-darwin9.0.0d1 > set build_triplet powerpc-apple-darwin9.0.0d1 > set target_triplet powerpc-apple-darwin9.0.0d1 > set target_alias powerpc-apple-darwin9.0.0d1 I know that we can switch on the target triplet. But the target triplet test doesn't determine whether, say, you've installed all of the required vendor patches; also, switching on target triplet isn't as easy to maintain as, say, switching on whether a platform supports weak symbols properly.
Re: libstdc++ XPASS's on Darwin
On Aug 17, 2006, at 11:42 AM, Jack Howarth wrote:
Well, I note sure how to handle some of these testcases. For
instance,
1_strings/basic_string/element_access/char/21674.cc has...
// { dg-require-debug-mode "" }
// { dg-options "-O0 -D_GLIBCXX_DEBUG" }
// { dg-do run { xfail *-*-* } }
Well, if it now passes everywhere, then the xfail clause can be
removed. I don't know if it does.
...which I assume implies that it really should only be set to fail
on systems which use glibc.
Nope. _GLIBCXX_DEBUG is the debug mode thing in the library,
unrelated to glibc.
Does the xfail statement have some boolean logic available so that
we can say xfail on all systems that aren't darwin8?
Not sure if it carries over, but other parts can do:
/* { dg-do compile { target { { i?86-*-* rs6000-*-* alpha*-*-* x86_64-
*-* } || { powerpc*-*-* && ilp32 } } } } */
so it might be possible. At worse, I think one can add a flag
conditionally, and then use the check_conditional_xfail functionality
to look for that flag.
target-suppports-dg has:
# Intercept the call to the DejaGnu version of dg-process-target to
# support use of an effective-target keyword in place of a list of
# target triplets to xfail or skip a test.
#
# selector is one of:
#xfail target-triplet-1 ...
#xfail effective-target-keyword
#xfail selector-expression
#target target-triplet-1 ...
#target effective-target-keyword
#target selector-expression
#
# For a target list the result is "S" if the target is selected, "N"
otherwise.
# For an xfail list the result is "F" if the target is affected, "P"
otherwise.
#
# A selector expression appears within curly braces and uses a single
logical
# operator: !, &&, or ||. An operand is another selector expression, an
# effective-target keyword, or a list of target triplets within quotes
or
# curly braces.
so it seems like one could make use of that if needed.
The 23_containers/vector/resize/1.cc is Radar 3884894
That was fixed in Tiger8H14 (aka 10.4.5) and later. I think it is
fine to require an up-to-date soft update status personally,
otherwise, one can do *-*-darwin8.[0-4] if one cared.
and can be fixed by just deleting "// { dg-do run { xfail *-*-
darwin8* } }".
I'm fine with that.
The 26_numerics/cmath/c99_classification_macros_c.cc xfail can
be fixed by just deleting the "*-*-darwin*" sections.
Bearing in mind Paolo's comment about past OS versions... You should
use darwin[0 7], if it now runs on 8 and you're unsure.
Lastly, 27_io/ios_base/storage/2.cc is Radar 3884894 (same as 1.cc)
and
explicitly notes that Darwin 8 fails because malloc doesn't return
a NULL even if an allocation fails. I assume that may have been fixed
by MacOS X 10.4.7.
Yes, it was, but also fixed by 10.4.5, see comment above.
Re: libstdc++ XPASS's on Darwin
Paolo, I would argue that if the failures are targeted at Darwin8, which is MacOS X 10.4, and the problems are resolved in a later point release like 10.4.7, they should be marked as as passing. The point releases on MacOS X are free and contain essential security fixes. Encouraging users to not stay current with their OS security fixes should not be a goal of the gcc developers. Jack
Getting at basic block info from an insn
Two part question: 1) Does the control flow graph exist at the time we're emitting assembler instructions? 2) If so, how do I go at getting at the basic block info, specifically successor info, if the only thing I have is a rtx for a conditional jump insn? Okay, maybe a 3-part question. Given said jump insn handle, I'm trying to find out if either of the targets is a loop exit. Is there an easier way to do so than finding the successor arcs and seeing if either is flagged as a loop exit? Thanks, Pat
Re: Getting at basic block info from an insn
> > Two part question: > > 1) Does the control flow graph exist at the time we're emitting assembler > instructions? > > 2) If so, how do I go at getting at the basic block info, specifically > successor info, if the only thing I have is a rtx for a conditional jump > insn? > > > Okay, maybe a 3-part question. Given said jump insn handle, I'm trying to > find out if either of the targets is a loop exit. Is there an easier way > to do so than finding the successor arcs and seeing if either is flagged as > a loop exit? Higher level reasoning for above questions. I'm looking for an alternate approach to the branch probability problem I encountered. Approach I'm considering is to recognize when a branch is a loop exit and prohibit appending any PowerPC branch hints. -Pat
Re: _JNI_CreateJavaVM missing
On Aug 8, 2006, at 5:56 AM, Andrew Haley wrote:
Juerg Lehni writes:
I compiled the lastest GCJ from SVN head today, and when linking to
my application that uses JNI invocation and worked well before, I
recieved a "undefined symbols" error about _JNI_CreateJavaVM and
_JNI_GetDefaultJavaVMInitArgs.
And indeed, these symbols seem not to be exported anymore, as this
does not show any results:
nm /usr/local/lib/libgcj.7.0.0.dylib | grep _JNI_CreateJavaVM
Is this a mistake on my side, or did something change here in the
meantime? I previously used gcc 4.1.1.
The only modification I made was to apply the patch I posted earlier
on this list:
http://gcc.gnu.org/ml/java/2006-06/msg00143.html
There have been some recent weirdnesses to do with Darwin symbols.
? I'm not sure what this refers to. I can guess at things that this
might refer to:
void gets asm("gets$UNIX2003");
or weird stuff like that on newer OSes. But, for the case in question
I don't see a relationship? No, I don't have any idea off the top of
my head about the issue raised above.
gcc-4.0-20060817 is now available
Snapshot gcc-4.0-20060817 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060817/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 116230 You'll find: gcc-4.0-20060817.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060817.tar.bz2 C front end and core compiler gcc-ada-4.0-20060817.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060817.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060817.tar.bz2 C++ front end and runtime gcc-java-4.0-20060817.tar.bz2 Java front end and runtime gcc-objc-4.0-20060817.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060817.tar.bz2The GCC testsuite Diffs from 4.0-20060810 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
Re: Getting at basic block info from an insn
> > > Two part question: > > 1) Does the control flow graph exist at the time we're emitting assembler > instructions? Not really because we delete the CFG because some passes right after the last scheduling does not understand CFG (reorg is one example). Thanks, Andrew Pinski
Re: Darwin -m64 results
FX,
That was spot on. If I reduce the test case down to...
! { dg-do run }
! Program to test ASSIGNing a label to common variable. PR18827.
program test
integer i
common i
end
I still get the linkage error...
gfortran -O3 -g -m64 assign.f90
can't find atom for N_GSYM stabs i:G(0,3) in /var/tmp//cct3ktdf.o
This happens with the -g flag and -m64 at all optimization levels.
The problem doesn't occur if I don't link the program. The .s for
the above file shows...
.machine ppc64
.stabs "/Users/howarth/",100,0,7,Ltext0
.stabs "assign.f90",100,0,7,Ltext0
.text
Ltext0:
.stabs "gcc2_compiled.",60,0,0,0
.align 2
.globl _MAIN__
_MAIN__:
.stabd 68,0,3
LFBB1:
.stabd 68,0,3
li r3,70
li r4,127
li r5,0
b L__gfortran_set_std$stub
.stabs "MAIN__:F(0,1)=(0,1)",36,0,3,_MAIN__
.stabs "void:t(0,1)",128,0,0,0
Lscope1:
.stabs "",36,0,0,Lscope1-LFBB1
.comm ___BLNK__,4
.stabs
"__BLNK__:G(0,2)=s4i:(0,3)=r(0,3);-2147483648;2147483647;,0,32;;",32,0,3,0
.stabs "int4:t(0,3)",128,0,0,0
.stabs "__BLNK__:G(0,2)",32,0,3,0
.stabs "i:G(0,3)",32,0,4,0
.stabs "",100,0,0,Letext0
Letext0:
.section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32
.align 5
L__gfortran_set_std$stub:
.indirect_symbol __gfortran_set_std
mflr r0
bcl 20,31,"L001$spb"
"L001$spb":
mflr r11
addis r11,r11,ha16(L__gfortran_set_std$lazy_ptr-"L001$spb")
mtlr r0
ldu r12,lo16(L__gfortran_set_std$lazy_ptr-"L001$spb")(r11)
mtctr r12
bctr
.lazy_symbol_pointer
L__gfortran_set_std$lazy_ptr:
.indirect_symbol __gfortran_set_std
.quad dyld_stub_binding_helper
.subsections_via_symbols
Geoff, I assume the linker is choking on the line...
.stabs "i:G(0,3)",32,0,4,0
...right?
Jack
Re: Darwin -m64 results
On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote: I assume the linker is choking on the line... .stabs "i:G(0,3)",32,0,4,0 ...right? Yes. The linker is complaining that there is no _i in the program. If you add one, it would have worked. I'm asking our linker and debugger people what they think.
Re: Darwin -m64 results
On Aug 17, 2006, at 5:43 PM, Mike Stump wrote: On Aug 17, 2006, at 4:26 PM, Jack Howarth wrote: I assume the linker is choking on the line... .stabs "i:G(0,3)",32,0,4,0 ...right? Yes. The linker is complaining that there is no _i in the program. If you add one, it would have worked. I'm asking our linker and debugger people what they think. Our linker guy said: It is a warning, not an error. It looks to me like it is correctly warning. There is no global variable "i". Is the fortran compiler optimizing away the storage, but forgetting to remove the corresponding stabs? In the asm for it I see: _i.0.875: .long -2 .lcomm _i.1.876,4,2 .stabs "i:G(0,3)",32,0,1,0 so, we have two i variables, and the stabs refers to neither.
