Where did Acovea go?

[Ben Elliston]

I'm interested in revisiting Acovea for some academic work I am doing,
but www.coyotegulch.com seems to have vanished off the net.  The last
post I could find from Scott Robert Ladd was October 2004.

Does anyone know where Scott and/or his web pages went?

Thanks,
Ben


pgpwz5HR1ZWaB.pgp
Description: PGP signature

SV: Where did Acovea go?

[Christian Joensson]

A trail here: http://chaoticcoyote.blogspot.com/

Cheers,

/ChJ


-Ursprungligt meddelande-
Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Ben Elliston
Skickat: den 5 mars 2005 13:25
Till: gcc@gcc.gnu.org
Ämne: Where did Acovea go?

I'm interested in revisiting Acovea for some academic work I am doing,
but www.coyotegulch.com seems to have vanished off the net.  The last
post I could find from Scott Robert Ladd was October 2004.

Does anyone know where Scott and/or his web pages went?

Thanks,
Ben

Re: Pascal front-end integration

[Joseph S. Myers]

On Sat, 5 Mar 2005, Waldek Hebisch wrote:

> GPC uses backend data structure when possible. I see no reason to
> duplicate backend functionality (Ada front is written in Ada, so they
> _had to_ duplicate a lot of infrastructure). We can hide (and are doing
> that now) most differences in macros.

Front end structures - as used by Ada, gfortran and gcjx - can be tailored 
to representing accurately the semantics of the source program as required 
by the language specification.  Whereas trees are now tailored to code 
generation with semantics for GENERIC/GIMPLE which are in the process of 
being documented and should not depend on the source language.  The tree 
semantics do not necessarily correspond to exactly what the Pascal 
standards require or to the particular information which a Pascal front 
end should maintain.

> But there are few tricky questions: I old backends want us to call a
> function is it OK to always call a wrapper (empty for new backend)?

I don't suppose such cleanly encapsulated compatibility with old back ends 
would need to block inclusion of GPC in GCC as long as when built with the 
current back end GPC builds just like the rest of GCC does (in terms of 
both relevant documented coding standards and e.g. the way in which 
Make-lang.in rules are written) and in general the code follows the GNU 
Coding Standards and the GCC Coding Conventions apart from such 
compatibility hooks.  I think it would however need to be understood that 
the rules for testing patches remain as now, testing with mainline, and 
it's up to the GPC maintainers to fix things up after changes breaking 
compatibility with old back ends to make the old back ends work again.  
This is especially the case for global changes affecting the front-end 
interface.

I also don't recommend trying to keep compatibility before 4.0; working 
with 4.0 would suffice to keep the new GPC developments usable with a GCC 
release and the differences between 4.0 and earlier compilers are 
sufficiently large that the saving from not trying to be compatible with 
earlier versions would be substantial.  In general, compatibility with the 
most recent release series should suffice; if the 4.0 series is 
insufficiently stable, effort would better be devoted to improving it than 
to keeping compatibility with older and less-maintained series.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.

[Michael N. Moran]

Frank Ch. Eigler wrote:
Karel Gardas <[EMAIL PROTECTED]> writes:

[...]
class Foo
{
public:
   virtual unsigned short
   iiop_version() const = 0;
};
and when I compile it, GCC emits warning from subject, although this class
is really abstract and will never be instantiated. [...]

I guess GCC assumes that some instances of a derived class will
eventually exist, and will be dealt with via a Foo* abstract pointer.
Is it common to never attempt to delete it via that Foo* value (which
would require a virtual destructor)?
In embedded system work, and I'm sure in other circumstances,
it is the case that "placement new" is the norm and destructors
invoked explicitly (never on an abstract reference,) and the
delete operator goes unused.
It is also true that embedded systems are resource constrained
and that in keeping with the C++ philosophy of not paying for
things that are not used, any unused storage overhead created
by *requiring* a virtual destructor is ... not good.
To make matters more interesting, I *always* compile with -Werror.
I am (shamefully) un-aware of any --no-virtual-destructor-warning
style flag, that would allow me to compile under these conditions
without adding the virtual destructor to all of my many abstract
base classes.
IOW, it's bad juju in some programming styles/domains, but not
in others.
back to lurking...
--
Michael N. Moran   (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144http://mnmoran.org
"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.

[Jonathan Wakely]

On Sat, Mar 05, 2005 at 09:00:38AM -0500, Michael N. Moran wrote:

> In embedded system work, and I'm sure in other circumstances,
> it is the case that "placement new" is the norm and destructors
> invoked explicitly (never on an abstract reference,) and the
> delete operator goes unused.

I should never have just said "add a virtual dtor" without qualification
:)

I assume in specialised domains where you have to know what you're
doing you will also know whether a virtual dtor is appropriate (and
can use -Wno-non-virtual-dtor to suppress the warning). If you're not
sure who might use the class and what they'll do, you have to be more
careful.

I was too quick to suggest adding the virtual dtor, clear documentation
that says "don't use delete with this type" might do the job equally
well - the important thing is to prevent the problem happening.

jon

-- 
Message terminated with signal 11, SIGFAULT

Re: matching constraints in asm operands question

[Jason Merrill]

On Sat,  5 Mar 2005 00:24:10 -0500, [EMAIL PROTECTED] wrote:

>> static __inline__ void atomic_add(atomic_t *v, int i)
>> {
>>  __asm__ __volatile__("addl %1,%0" : "+m" (*v) : "d" (i));
>> }
>>
>> Then the compiler complains with:
>>
>> /asm/atomic.h:33: warning: read-write constraint does not allow a register
>>
>> So is the warning wrong?
>
> Yes, the warning is wrong, and the text in the manual about '+' is also
> nonsense.  Support for '+' is asms was specifically introduced to make
> it safe to have read-write memory operands.  Jason, the point of using '+'
> is that the matched parts start out as the same, and the compiler is
> supposed to keep them the same.

Well, I assumed the same thing when I started poking at that code, but then
someone pointed out that it didn't actually work that way, and as I recall
the code does in fact assume a register.  I certainly would not object to
making '+' work properly for memory operands, but simply asserting that it
already does is wrong.

Jason

Re: matching constraints in asm operands question

[amylaar]

Quoting Jason Merrill <[EMAIL PROTECTED]>:

> Well, I assumed the same thing when I started poking at that code, but then
> someone pointed out that it didn't actually work that way, and as I recall
> the code does in fact assume a register.  I certainly would not object to
> making '+' work properly for memory operands, but simply asserting that it
> already does is wrong.

The code in reload to make non-matching operands match assumes a register.
However, a match from a plus should always kept in sync (except temporarily
half-way through a substitution, since we now unshare).  If it isn't,
that's a regression.  Do you have a testcase, and/or can point out the code
that introduces the inconsistency in the rtl?

MetaC++ announcement

[Stefan Strasser]

I've written a library which isn't exactly on-topic of gcc development,
but is gcc related and there have been multiple requests for a gcc
feature like this on the list(-fdump-translation-unit...), so here is
some information about it:
What?
-
MetaC++
It is a library which is able to read and write C++ source code and
makes the tree available to its clients by API and by a XML format it
can read and write.
Parsing is done by a patched GCC.
The tree is a representation of language constructs, not a syntax tree.
Why?
-
It's primarily aimed at source-to-source code translators, but can also
be used by source code analysis tools, stub generators, source-to-UML
converters, etc.
By using GCC as parser it has good C++ language support.
Where?
-
http://www-user.uni-bremen.de/~strasser/metacpp/
Language Support? Status?
-
"Alpha" status.
Full C++ should work, including templates. It has been tested with C++
STL and parts of boost.
Statements, i.e. function bodies, are ignored in this version, so no
full translation yet, but it's already usable for header translation and
source code analysis which don't need bodies.
The most common expressions for initializers and template specialization
arguments are supported. Others are still ignored, and will be supported
in the next version along with function bodies.
Rewriting of boost is not yet working completely because of advanced
initializer expressions to constants which are then used as
instantiation arguments, reading works.
(Library is still leaking a few hundred kilobytes each gcc invocation,
I'd appreciate help with this, see previous mail on the list)

API Documentation?
-
UML Diagrams:
http://www-user.uni-bremen.de/~strasser/metacpp/uml.pdf
XML Example?
-
C++ std string header as gzipped XML:
http://www-user.uni-bremen.de/~strasser/metacpp/string.xml.gz
There are many other things included from this header, one of the last
TemplateClassDefinitions inside NamespaceDefinition "std" is
"std::basic_string". (Id 10339)
Generated output:
http://www-user.uni-bremen.de/~strasser/metacpp/string.cpp

Code Example?
-
Virtually inherit all classes from class "base":
object base;
//find or create "base"
object tu;
Code::InputFile input("in.cpp");
input >> tu;
TranslationUnit::tree_iterator
it=tu->find_recursive();
for(;it != tu->end();++it){
object baseSpec=BaseSpecifier::New();
baseSpec->SetClass(base);
baseSpec->SetVirtual();
it->GetBases().push_back(baseSpec,*it);
}
Code::OutputFile output("out.cpp");
output << tu;

You never want to change all elements, including STL etc.!
-
Yes. There will be some mechanism to mark elements with attributes when
it is source-to-source ready(see "Language Support"), something like:
persistent class MyDatabaseObject;
distribute void function();
For now you can decide this only by language constructs(its name, what
namespace it is in, etc.)
XML format?
-
You can use the library for reading and writing. However, the xml format
is automatically derived from the object model,data field "isVirtual"
in class "BaseSpecifier" is called "BaseSpecifier.IsVirtual" in xml
files. Normal fields and pointer<>'s are attributes, element<>'s and
list<>'s are subnodes.

--
Stefan Strasser

Re: MetaC++ announcement

[Florian Weimer]

* Stefan Strasser:

> What?
> -
> MetaC++
> It is a library which is able to read and write C++ source code and
> makes the tree available to its clients by API and by a XML format it
> can read and write.
> Parsing is done by a patched GCC.
> The tree is a representation of language constructs, not a syntax tree.

Does it include representation information, e.g. offsets of class
members?  Unfortunately, the XML sample is too unwieldy to tell. 8-/

Re: MetaC++ announcement

[Stefan Strasser]

Florian Weimer schrieb:
The tree is a representation of language constructs, not a syntax tree.

Does it include representation information, e.g. offsets of class
members?  Unfortunately, the XML sample is too unwieldy to tell. 8-/
it does preserve order of members, so processed source is compatible 
with unprocessed source.
it does not read any variable alignment information(except c++ bitfield 
size) and I don't see a reason to do that.
but in case you need that it can be added quite easily, search for 
"Parse(object


--
Stefan Strasser

cgraph_remove_node still slow

[Richard Guenther]

Hi!
For a tramp3d -O2 compile we still have
Flat profile:
Each sample counts as 0.01 seconds.
  %   cumulative   self  self total
 time   seconds   secondscalls   s/call   s/call  name
  5.10  4.53 4.53   129961 0.00 0.00  cgraph_remove_node
  2.93  7.13 2.60 28401225 0.00 0.00  ggc_alloc_stat
  1.65  8.60 1.47 11131801 0.00 0.00 
splay_tree_splay_helper
  1.38  9.83 1.23 17375270 0.00 0.00  get_stmt_operands
  1.34 11.02 1.19 13906935 0.00 0.00 
htab_find_slot_with_hash

with is probably the loop(s) over all clones in cgraph_remove_node which
results in all this being O(n^2) inlining all of the clones.
The obvious fix for the first loop, the removal of the node from the
clones list, is to make this list doubly-linked, there is another loop
just a few lines below with the same complexity:
 for (n = *slot; n; n = n->next_clone)
if (n->global.inlined_to
|| (!n->global.inlined_to
&& !TREE_ASM_WRITTEN (n->decl) && 
!DECL_EXTERNAL (n->decl)))
  break;
  if (!n && !dump_enabled_p (TDI_tree_all))
{
  DECL_SAVED_TREE (node->decl) = NULL;
  DECL_STRUCT_FUNCTION (node->decl) = NULL;
  DECL_INITIAL (node->decl) = error_mark_node;
}

which checks if we still need the function body.  Why is this loop there
in the first place?  Wouldn't it be enough to check this if the node is
the last clone?  Why do we need the list of clones anyway?  It looks 
like its purpose can be achieved with some reference counting, too?

Any ideas how to fix this remaining O(N^2) complexity for 4.0?
Thanks,
Richard.

gcc-4.0-20050305 is now available

[gccadmin]

Snapshot gcc-4.0-20050305 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050305/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050305 

You'll find:

gcc-4.0-20050305.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20050305.tar.bz2 C front end and core compiler

gcc-ada-4.0-20050305.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20050305.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20050305.tar.bz2  C++ front end and runtime

gcc-java-4.0-20050305.tar.bz2 Java front end and runtime

gcc-objc-4.0-20050305.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20050305.tar.bz2The GCC testsuite

Diffs from 4.0-20050226 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.

Things blocking fold_ARITY and fold_buildN

[Kazu Hirata]

Hi,

The uses of the whole expression in the current fold_ARITY are
blocking transition to fold_ARITY (code, type, op0[, op1[, op2]]).

Below I am showing places where we need to make changes in the form of
a patch.  Wherever 't' is used, we need to make changes.

The first hunk comes from fold_unary, and the last one comes from the
fold_ternary.  The rest comes from fold_binary.

I've already got suggestions from Zack and Roger for fold_ternary.  I
think I'll replace a call to fold_builtin with fold_builtin_1 and
change fold_builtin_1 to take fn, arglist, and possibly static chain
if needed (as suggested by Roger on IRC).

COMPARISON_CLASS_P (t) is easy because it's equivalent to
TREE_CODE_CLASS (code) == tcc_comparison.

I might need help on others.  I'll try to go through these "KAZU" one
by one, but if you could volunteer to fix one, you are more than
welcome.  Suggestions like "Here is what I would do" would be fine,
too.

Kazu Hirata

diff -u fold-const.c fold-const.c
--- fold-const.c6 Mar 2005 00:44:01 -
+++ fold-const.c6 Mar 2005 00:45:38 -
@@ -6802,6 +6802,7 @@
{
  /* Don't leave an assignment inside a conversion
 unless assigning a bitfield.  */
+ /* KAZU.  */
  tem = copy_node (t);
  TREE_OPERAND (tem, 0) = TREE_OPERAND (op0, 1);
  /* First do the assignment, then return converted constant.  */
@@ -7152,6 +7153,7 @@
 
   if (TREE_CODE (arg0) == COND_EXPR || COMPARISON_CLASS_P (arg0))
{
+ /* KAZU.  */
  tem = fold_binary_op_with_conditional_arg (t, code, arg0, arg1, 
 /*cond_first_p=*/1);
  if (tem != NULL_TREE)
@@ -7160,6 +7162,7 @@
 
   if (TREE_CODE (arg1) == COND_EXPR || COMPARISON_CLASS_P (arg1))
{
+ /* KAZU.  */
  tem = fold_binary_op_with_conditional_arg (t, code, arg1, arg0, 
 /*cond_first_p=*/0);
  if (tem != NULL_TREE)
@@ -7170,6 +7173,7 @@
   switch (code)
 {
 case RANGE_EXPR:
+  /* KAZU.  */
   if (TREE_CONSTANT (t) != wins)
{
  tem = copy_node (t);
@@ -8611,6 +8615,7 @@
}
 
   /* See if we can build a range comparison.  */
+  /* KAZU.  */
   if (0 != (tem = fold_range_test (t)))
return tem;
 
@@ -8727,6 +8732,7 @@
   /* If this is a comparison of two exprs that look like an
 ARRAY_REF of the same object, then we can fold this to a
 comparison of the two offsets.  */
+  /* KAZU.  */
   if (COMPARISON_CLASS_P (t))
{
  tree base0, offset0, base1, offset1;
@@ -9142,6 +9148,7 @@
   && (TREE_CODE (arg0) == MIN_EXPR
   || TREE_CODE (arg0) == MAX_EXPR)
   && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST)
+   /* KAZU.  */
return optimize_minmax_comparison (t);
 
   /* If we are comparing an ABS_EXPR with a constant, we can
@@ -9845,6 +9852,7 @@
  && TREE_CODE (TREE_OPERAND (op0, 0)) == FUNCTION_DECL
  && DECL_BUILT_IN (TREE_OPERAND (op0, 0)))
{
+ /* KAZU.  */
  tree tmp = fold_builtin (t, false);
  if (tmp)
return tmp;

Re: Things blocking fold_ARITY and fold_buildN

[Kazu Hirata]

Hi,

> I might need help on others.  I'll try to go through these "KAZU" one
> by one, but if you could volunteer to fix one, you are more than
> welcome.  Suggestions like "Here is what I would do" would be fine,
> too.

Roger kindly suggested what to do for each of these on IRC.

Kazu Hirata

How is lang.opt processed?

[Steve Kargl]

I'm looking to the broken behavior of gfortran with its
-r8, -i8, and -d8 options.  gfortran/lang.opt contains


d8
F95 RejectNegative
Set the default real and integer kinds to double precision

i8
F95
Set the default integer kind to double precision

r8
F95
Set the default real kind to double precision


I have modified gfortran/options.c as follows:

case OPT_i8:
  gfc_option.i8 = value;
  printf("i8 = %d\n", gfc_option.i8);
  break;

case OPT_r8:
  gfc_option.r8 = value;
  printf("r8 = %d\n", gfc_option.r8);
  break;

case OPT_d8:
  gfc_option.i8 = value;
  gfc_option.r8 = value;
  printf("i8 = %d\n", gfc_option.i8);
  printf("r8 = %d\n", gfc_option.r8);
  break;

I now process a test file:

kargl[216] cat hy.f90
program hy
   real x
   integer i
   x = 1.e0
   i = 2
   print *, x
   print *, i
end program hy
kargl[217] gfc41 -static -o z -d8 hy.f90
i8 = 0
r8 = 0
i8 = 1
r8 = 1
kargl[218] ./z
   1.00 
2
kargl[219] gfc41 -static -o z -i8 hy.f90
i8 = 0
r8 = 0
kargl[220] ./z
   1.00
   2
kargl[221] gfc41 -static -o z -r8 hy.f90
gfc41: unrecognized option '-r8'
i8 = 0
r8 = 0
kargl[222] ./z
   1.00
   2
kargl[223] gfc41 -static -o z hy.f90
i8 = 0
r8 = 0

So, -d8 works as expected, but -i8 and -r8 are completely ignored
by gfortran.  It appears that the processing of lang.opt is 
broken.  Any insight into the broken nature of processing would
be appreciate.

-- 
Steve

Re: mudflap abort

[Eyal Lebedinsky]

Now tracked as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20339
--
Eyal Lebedinsky ([EMAIL PROTECTED]) 
attach .zip as .dat

Re: invoke.texi: reference to web page that does not exist

[Giovanni Bajo]

Devang Patel <[EMAIL PROTECTED]> wrote:

> invoke.texi mentions following URL for further info on visibility
> #pragmas.
>http://www.nedprod.com/programs/gccvisibility.html
> but it does not exist.


The page was up and working no longer than 2 weeks ago. Niall Douglas (which
I'm CC:ing) is the owner of that page.
Niall, are you planning to get the site back up and running soon? If not, can
we get a copy of gccvisibility.html so that we can extract the text and host it
locally?

Thanks
Giovanni Bajo

Re: [PING] [PATCH]: New Port(MAXQ)

[Giovanni Bajo]

Konark Goel, Noida <[EMAIL PROTECTED]> wrote:

>  We submitted a patch for a new port for MAXQ architecture.
>  The original patch is
> (http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02138.html)
>  The revised patch after incorporating few comments is
> (http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00521.html)
>  Please let us know if that patch is acceptable.

Can you also post the result of a testsuite run to the testresult mailing list
to make sure the port is somewhat stable?
Was the copyright assignment to FSF filed for either the whole company or the
authors of the port?

Mark, how does this port fit in the 4.1 plan? Since it is totally
self-contained (it does not modify anything in GCC proper but the usual
configuration additions), I think it could be merged any time, assuming a
global maintainer can spend some time on a review. To be fair, this patch was
posted last December with mainline in Stage 3 (and got almost no comments), so
if the patch is approved, it could be added to 4.0 too (given absolutely zero
risk).

Giovanni Bajo