HDTenEightyP/NetNews huggingface dataset:
From: icmv!mtranle%paris@uunet.UU.NET (Minh Tran-Le)
Newsgroups: comp.compilers
Subject: Re: xlc for RS6000 -0 flag
Keywords: C, IBM
Date: 11 Sep 92 05:28:35 GMT
Reply-To: icmv!mtranle%paris@uunet.UU.NET (Minh Tran-Le)
Organization: IntelliCorp Inc.

jpennell@axion.bt.co.uk (John Pennell) writes:

>Can anyone help?

>Are there any known bugs with the optimisation feature on xlc (AIX 3.2).
>When compiling on one particular file, the compiler appears to "hang" for
>10 minutes.  When I inspect memory usage, it shows that AVM is being used
>at a very high rate, during the last few minutes, the process is only
>slowed by the pagin in and out of memory!

>The compilation eventually fails with the message "compilation failed -
>out of space" (or something like that). ...

There is a bug with the ibm rs6000 xlc compiler goes to infinite loop
trying to optimize code with unused variable.  This occurs when you when
you use the compiler as xlc or c89 because the default setting enable the
`-qansialias' flag in /etc/xlc.cfg.

You can work around it by removing the `-qansialias' from the default
flags in the config file /et/xlc.cfg. This is will make it hang less.  Or
remove any unused variable from your functions.

I have already reported that problem to ibm support.  Also if you haven't
got the latest version of the xlc compiler (1.2.0.12 at least) you should
call up ibm support and ask for it because it fixes a bunch of bugs.
(Except the one we are talking about).  The newer version of the xlc
compiler still hangs while trying to do certain optimization but it does
not run out of paging space anymore.

Minh Tran-Le.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: rob@guinness.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.compilers,comp.human-factors
Subject: Re: language design tradeoffs
Keywords: design, parse, comment
Date: 14 Sep 92 04:43:27 GMT
Reply-To: rob@guinness.eng.ohio-state.edu (Rob Carriere)
Organization: The Ohio State University Dept of Electrical Engineering

weberwu@inf.fu-berlin.de (Debora
Weber-Wulff) writes: 
>raveling@Unify.com (Paul Raveling) writes:
>[sick macro trap in C deleted]
>Sigh. The problem is not the ';', it's the syntax of the if statement. If
>';' were nothing more than a statement separator and the empty statement
>were allowed, we could write ';;;;;;;;;;;;;;;;' if we felt like it. Then
>'if' must be terminated with a nice 'fi'and the problem goes away. Another
>reason why explicit terminators like od and fi are a good idea!

True.  It is, however, possible to achieve the same effect in languages
that don't require if/do terminators by religously making the statement
inside the if/do a block; i.e. always use {} or BEGIN/END or whatever it's
called in the language of the week.

In fact, I would argue that a language that requires coding that way has
superior syntax to a do/od language, because of the well-known problem
with the spelling of the terminators.  Things like TNEMMOC, CNUF and NIGEB
start looking OD rather quickly.

SR
---
[Algol68 came close to TNEMMOC, but also did an amazing job of letting you
use parentheses, vertical bars, and the like, as synonyms for if, else, fi,
begin, end, and other common delimiters. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: jpennell@axion.bt.co.uk (John Pennell)
Newsgroups: comp.compilers
Subject: xlc for RS6000 -0 flag
Keywords: C, question, IBM
Date: 8 Sep 92 14:35:38 GMT
Reply-To: jpennell@axion.bt.co.uk (John Pennell)
Organization: British Telecom Research Labs

Can anyone help?

Are there any known bugs with the optimisation feature on xlc (AIX 3.2).
When compiling on one particular file, the compiler appears to "hang" for
10 minutes.  When I inspect memory usage, it shows that AVM is being used
at a very high rate, during the last few minutes, the process is only
slowed by the pagin in and out of memory!

The compilation eventually fails with the message "compilation failed -
out of space" (or something like that).  Meanwhile, the server warns it is
low on paging space.  Obviously, there is something in this file which
causes the optimiser to fail - I have no idea what it could be.  There are
no tight loops - help would be appreciated.

Post or E-Mail.

Jon
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: ipser@solomon.technet.sg (Ed Ipser)
Newsgroups: comp.compilers
Subject: Re: Backtracking yacc
Keywords: yacc, parse, LR(1)
Date: 11 Sep 92 07:36:32 GMT
Article-I.D.: comp.92-09-062
Reply-To: ipser@solomon.technet.sg (Ed Ipser)
Organization: TECHNET, Singapore

The moderator comments:
>[That might help for conflicts in an unambiguous grammar that needs more than
>one token lookahead, but not for the more common case that a conflict is due
>to a truly ambiguous grammar.  Besides, isn't there a theorem that says that
>any LR(k) grammar can be rewritten as LR(1)? -John]

Such theorems are rarely of practical value; in practice you will find
that rewriting an LR(k) grammar to be LR(1) (or whatever) will involve
contorting the original syntax in ways that are perverse. While such a
contortion might be acceptable for parsing alone, attempting to add simple
semantic actions or, worse, trying to maintain the grammar for an evolving
language can lead to premature greying. The Roskind C++ grammar is a
notorious example.

As for backtracking, there are additional problems: again, what about
semantic processing? If you are merely parsing or constructing a parse
tree, you can get away with throwing away an incorrect guess. But as soon
as you introduce side effects of even the simplest nature, you are left
with the task of figuring out how to undo actions associated with the
wrong guess. Even for a language as simle as Ansi C, you must perform
certain semantic actions just to parse and C++ is even worse.

A far better approach is to have available a set of tools which allow the
disambiguation at the point where it is first encountered. LADE, for
example, allows context-sensitive tests to be performed. These can be used
to either a) test arbitrary semantic information to decide on a path to
take, or b) parse ahead in parse-only mode to find some disambiguating
symbol, then return and resume normal, action-associated, parsing. While b
approaches a back-tracking capability, it is not, in fact, backtracking
since it returns to the originating point regardless of what symbols were
found in the scan- ahead.

(For information on LADE please contact xorian@solomon.technet.sg)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Gary Merrill <sasghm@unx.sas.com>
Subject: Re: Backtracking yacc
Reply-To: Gary Merrill <sasghm@unx.sas.com>
Organization: Compilers Central
Date: Fri, 11 Sep 1992 12:30:46 GMT
Keywords: yacc, C++, parse

> Has anybody seen such a thing as backtracking yacc?  What I had in mind
> was a LALR parser that resolves ambiquity by backtracking to the point
> where it had multiple routes to go.  It would parse the input until it
> encounters a dead end, and after that it would try an alternative path.
> 
> I know this would not solve much.  Resolving the the conflicts 'the wrong
> way' can still result to an errorless parsing, but I would like to know if
> there have been any study about this approach.  Is this a completely dead
> idea ?

Our C++ parser uses a yacc-generated parser that is recursively callable
in order to resolve the ambiguities in C++.  I have modified a version of
Berkeley yacc in several (not very complicated) ways to support this
approach.  The underlying yacc parser will of course not correctly parse a
non-LR(k) grammar by itself, but given the added features and using a
technique of "trial parsing" (such as that hinted at in the above
posting), it is possible to parse the desired ambiguities -- and more
generally, it is possible to parse non-LR(k) grammars.  A paper describing
the implementation of the changes to yacc, the technique of trial parsing,
the role of the lexical analyzer, techniques required in constructing the
yacc grammar, and examples of parsing ambiguities in C++ has been
submitted to a journal.  I suppose I could make draft copies of this
available on an individual basis to those interested.

Having done all this, I am still rather uncertain as to its value.  (The
paper explains briefly why I went this route, and the reasons pertained
largely to practical concerns, scheduling, etc. rather than to technical
issues.)  The approach certainly seems to work.  It is quite powerful.
But I think if I had it to do over again I would use a recursive descent
parser.
---
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: kers@otter.hpl.hp.com (Chris Dollin)
Newsgroups: comp.compilers
Subject: Re: Introducing new operators (was: Re: Scientists as Programmers)
Keywords: C++, parse
Date: 11 Sep 92 13:57:23 GMT
Reply-To: kers@otter.hpl.hp.com (Chris Dollin)
Followup-To: comp.compilers
Organization: Hewlett-Packard Laboratories, Bristol, UK.

In article ... fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

  >>  C++ allows you to overload existing operators, although to make compiler
  >>  writer's jobs easier, it does not allow you to introduce new operators.
  >>
  >[argument whether it's nearly impossible, trivial, or somewhere between]

  I think that "next to impossible" is perhaps overstating the case a
  little.  [...]

   All the same, it is not trivial. If you also have to worry about backwards
   compatability with C, it becomes very difficult indeed, I suspect.

And in my original message (the intro to which appears above), I did note that
compatability with C did present C++ language designers with a problem, viz,
preserving its lexis, if they wanted to have user-defined operators.

In a follow-up in comp.lang.misc, I have also noted that user-defined operator
(name) 's do not require user-define dprecedences, and that in fact I am happy
for the language to have a well-chosen *single* precedence for UDOs. This, I
submit, *does* make UDOs ``trivial'' to implement.

So long as they are designed in from the start, and not hacked on later.
--

Regards,
Kers.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1552 comp.lang.c++:13703
From: ipser@solomon.technet.sg (Ed Ipser)
Newsgroups: comp.compilers,comp.lang.c++
Subject: Have C++ Parser; Need Difficult C++ Examples
Keywords: C++, parse,, comment
Date: 14 Sep 92 07:37:04 GMT
Reply-To: ipser@solomon.technet.sg (Ed Ipser)
Organization: National University of Singapore

We have developed a C++ parser (abstract translator, actually) which is
now in beta testing. We are looking for difficult C++ programs to test the
parser. It already successfully handles all publishd ambiguities including
several difficult examples posted to comp.compilers recently.

Please email your most difficult C++ cases to:
  Arthur Sombrito of Xorian Technologies
  arthur@solomon.technet.sg

Be sure to include a short description of why the case is supposed to be
difficult.

The LADE C++/AT (a.k.a. the Sombrito Grammar) provides complete semantic
information on the processed C++ program including:

  o  the class hierarchy;

  o  class data and function member signatures; and

  o  objects, types, and function signatures.

The LADE C++/AT is built within the LADE Translator Generator framework
using the abstract translator methodology which means that the LADE C++/AT
may be utilized in any number of ways:

  o  as a stand-alone semantic processor to provide semantic
     information;

  o  as the basis for customized semantic analysis, semantic
     checking, or code analysis;

  o  as the basis for full-fledged C++ compilers or interpreters; or

  o  as the basis of languages which are a superset or subset of C++
     (e.g. C++ with SQL).

For more information on LADE or LADE C++/AT please contact:
  xorian@solomon.technet.sg
  fax: (65)253-7709
[So can we see your parser? -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: mickunas@m.cs.uiuc.edu (Dennis Mickunas)
Newsgroups: comp.compilers
Subject: Re: Parsing wars
Keywords: parse, LR(1), bibliography
Date: 10 Sep 92 20:40:14 GMT
Article-I.D.: comp.92-09-060
Reply-To: mickunas@m.cs.uiuc.edu (Dennis Mickunas)
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

dww@inf.fu-berlin.de writes:

>jar@cheops.HQ.Ileaf.COM (Jim Roskind x5570) writes [about "strange parsing"]

>>The conseqeunces of this extension are quite significant, and the
>>resulting parser engine provides a much larger class of parsers than LR
>>parsers.  ...

>Oh yes, with backing up it seems you could parse a lot more languages
>like a^n b^n c^n ...

You can't quite get a^n b^n c^n with the straightforward 2-stack technique
that is suggested here.  It *is* possible to get a proper subset of the
non-deterministic cfl's.  For example, it is quite easy to obtain {a^n
b^n} U {a^n b^2n c}.  Non-canonical techniques for parsing such languages
have been around for some time.  Virtually all of them can be cast in the
form of a two-stack parser.  These non-canonical techniques include
Colmerauer's total precedence method [1], Williams' Bounded-Context
Parsable (BCP) method [2], Culik & Cohen's LR-Regular method [3],
Szymanski's LR(k,infinity) and Finite Phrase Finding Automaton Parsable
(FPFAP(k)) methods [4], Fischer's Synchronous Parsing Machines (SPM)
method [5], Tai's Noncanonical SLR (NSLR) and Leftmost Noncanonical SLR
(LSLR) methods [6], and finally, Schell's Generalized Piecewise LR (GPLR)
method [7].  In particular, Tai's TOPLAS paper provides a very readable
presentation of the technique.

[1] Colmerauer, A., "Total precedence relations," _JACM 17_, 1 (1970).

[2] Williams, J. H., "Bounded context parsable grammars," _Information
	Control_, 28 (1975).

[3] Culik, K. and R. Cohen, "LR - regular grammars - an extension of
	LR(k) grammars," _JCSS 7_, 1 (1973).

[4] Szymanski, T. G., "Generalized bottom-up parsing," PhD Thesis,
	Computer Science Department, Cornell University, Technical
	Report TR 73-168, Ithaca, New York (1973).

[5] Fischer, C. N., "On parsing context-free languages in a parallel
	environment," PhD Thesis, Computer Science Department, Cornell
	Universiy, echnical Report TR 75-237, Ithaca, New York (1975).

[6] Tai, K. C., "Noncanonical SLR(1) grammars," _TOPLAS 1_, 2 (1979).

[7] Schell, R. M., "Methods for constructing parallel compilers for use
	in a multiprocessor environment," PhD Thesis, Department of
	Computer Science, University of Illinois at Urbana-Champaign,
	Technical Report UIUCDCS-79-958, Urbana, Illinois (1979).

-- 

M. Dennis Mickunas                     
Department of Computer Science 		 1304 W. Springfield Ave.
University of Illinois			 Urbana, Illinois 61801
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: chow@sp1.csrd.uiuc.edu (Jyh-Herng Chow)
Newsgroups: comp.compilers
Subject: Re: Abstract Interpretation Query
Keywords: functional, logic
Date: 6 Sep 92 22:06:59 GMT
Reply-To: chow@sp1.csrd.uiuc.edu (Jyh-Herng Chow)
Organization: UIUC Center for Supercomputing Research and Development

Ashok Sreenivas <ashok@trddc.ernet.in> writes:
>What I want to know is: has anybody applied it to everyday imperative
>languages in real life (i.e. to languages like Pascal, C, and
>analyses like type analysis, data flow analysis etc.)?  

Yes, the Miprac compiler, a multilingual parallelizing compiler (for C,
Lisp, Fortran, etc) by W.L. Harrison and Z.Ammarguellat at CSRD uses a
very compilicated abstract interpretation for obtaining side-effects, data
dependences and object lifetimes information, for both numerical and
symbolic programs. For an overview of this compiler, see 

    "A Program's Eye View of Miprac", Williams L. Harrison and 
    Zahira Ammarguellat, in proc. 5th Workshop on Languages and Compilers 
    for Parallel Computing, Yale University, August, 1992

--
Jyh-Herng Chow (chow@csrd.uiuc.edu)
465 CSRL
1308 West Main Street
University of Illinois at Urbana-Champaign
Urbana, IL 61801-2307
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: nico@dutiag.twi.tudelft.nl (Nico Plat)
Newsgroups: comp.compilers
Subject: Literature needed on recursive (union) types
Keywords: types, design, question
Date: 15 Sep 92 15:02:35 GMT
Reply-To: nico@dutiag.twi.tudelft.nl (Nico Plat)
Organization: Compilers Central

Dear all,

I have the following problem:

Suppose I have a language with union types. A union type is a type 
denoting those values that are a member of at least one of its
component types. So, suppose I have a type definition T = nat | bool
(The '|' symbol is the type constructor for union types), then 1, 2, 3,
4, etc. would be values of T, but <false> and <true> as well. 

The problem arises when trying to determine subtype relations between
recursive union types. I want to define a relationship
`IsSubType (T1, T2)', which yields true if (all the components of) T1
are subtypes of (at least one of) the components of T2. 

Consider the two type definitons

	T1 = nat | nat X T1		{ 'X' denotes a product type }
	T2 = real | real X T2

IsSubType (nat, real) is defined to be true, and therefore it is easy
to see that IsSubType (T1, T2) should be true as well. The obvious
implementation does not work, however, because a recursive call to
IsSubType (T1, T2) is made when examing the second component, and then
we have infinite recursion. For this particular class of example a fix
could be found, but they can be made much more complex.

Does anyone know of literature dealing with this kind of problem?

Thanks for your time,

- Nico Plat                                                           -
- Delft University of Technology                                        -
- Fac. of Techn. Math. and Informatics                                    -
- P.O. Box 356, NL-2600 AJ Delft, The Netherlands                          -
- Phone +31-15784433 Fax +31-15787141 E-mail nico@dutiaa.twi.tudelft.nl      -
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1529 comp.human-factors:2122
From: vugranam@pike.ee.mcgill.ca (Vugranam Chakravarthy Sreedhar)
Newsgroups: comp.compilers
Subject: Re: Abstract Interpretation Query
Keywords: functional, logic
Date: 5 Sep 92 09:00:51 GMT
Reply-To: vugranam@pike.ee.mcgill.ca (Vugranam Chakravarthy Sreedhar)
Organization: McGill University - VLSI Laboratory, Montreal, CANADA.

Ashok Sreenivas <ashok@trddc.ernet.in> writes:
>I am working on trying to formalise program analyses and transformations.  In
>this connection, I have come across a technique called Abstract
>Interpretation.  So far, I've only seen a lot of theory regarding it, and
>some applications to functional and logic languages.

Yes. Recent Int. Conf. on Comp. Languages (1992) was mainly
devoted to Abstract Interpretation. The seminal paper was actually
targeted to imperative programs (Cousant and Cousant, POPL'78, I am right!!).
Recently the method was applied to functional/logic programming.

>What I want to know is: has anybody applied it to everyday imperative
>languages in real life (i.e. to languages like Pascal, C, and
>analyses like type analysis, data flow analysis etc.)?  

AI, although nice, is expensive in terms of time and space. I doubt if the
concept is being used in any production compilers. There are some research
experience on AI in various forms. Keshav Pingali at Cornell (POPL'90/91)
uses AI for dataflow analysis. Z. Ammarguellat and W. L. Harrison
III(Sigplan PLDI'90) use AI for recognizing recurrence relations. Recent
Intl. Conf. on Comp. Lang. has a on paper on pointer analyses based on AI.

Sreedhar

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: Alfred.Kayser@dnpap.et.tudelft.nl (Alfred Kayser)
Newsgroups: comp.compilers
Subject: Re: -O4 in SunOS compiler
Keywords: sparc, optimize, C, comment
Date: 4 Sep 92 08:01:40 GMT
Reply-To: Alfred.Kayser@dnpap.et.tudelft.nl (Alfred Kayser)
Organization: Delft University of Technology, Dept. of Electrical Engineering

dolf@toet.echo.tds.philips.nl (Dolf Grunbauer) writes:

>David Chase wrote:
>>>  * The compiler may produce 'wrong' code ...
>An interesting simple program might be the following C code.
>Depending on the level of optimalisation the answer varies.
>I tested this on Sun 4.1.1..
>Options -g, -O and -O2 give a 1 while -O3 and -O4 give 2.
>(This program has previously been dealt with in comp.lang.c):

Program deleted...

statement of importance: dummy(x.func(&x), x.func(&x));

You've demonstrated why it is bad practice to call functions, with
side-effects (ie they change the global status from within) in a context
where the exact calling sequence is undefined... Functions called to
produce arguments for another function can be called in random order...

Even this statement would produce unprodictable answers:
	dummy(x.val, x.func(&x)); 
as it is not defined that x.func is called after or before the value of
x.val is pushed on the stack...

About the optimization problems, the problem with misusing pointers
(aliasing things) is that not the optimizer goes wrong, but you did. Al
these examples of code which produce unprodictable answers, are very fine
examples of very bad programming practise. Even the best compilers can be
fooled...

Alfred
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --
[Enough already, we all know that it's easy to write C programs with
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1549 comp.human-factors:2206
From: weberwu@inf.fu-berlin.de (Debora Weber-Wulff)
Newsgroups: comp.compilers,comp.human-factors
Subject: Re: language design tradeoffs
Keywords: design, parse
Date: 13 Sep 92 12:34:30 GMT
Reply-To: weberwu@inf.fu-berlin.de (Debora Weber-Wulff)
Organization: Free University of Berlin

raveling@Unify.com (Paul Raveling) writes:
[sick macro trap in C deleted]

>then the extra ';' terminates the entire 'if' statement and the following
>'else' produces a syntax error.  Or if you had left yourself open to the
>dangling else problem in nested if's, it's possible to get no syntax error
>but instead to get a surprising flow of control.

Sigh. The problem is not the ';', it's the syntax of the if statement. If
';' were nothing more than a statement separator and the empty statement
were allowed, we could write ';;;;;;;;;;;;;;;;' if we felt like it. Then
'if' must be terminated with a nice 'fi'and the problem goes away. Another
reason why explicit terminators like od and fi are a good idea!
-- 
Debora Weber-Wulff                       dww@inf.fu-berlin.de
Institut fuer Informatik                 +49 30 89691 124
Nestorstr. 8-9
D-W-1000 Berlin 31
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,comp.human-factors