headers
Mark Mitchell | 1 Apr 2006 01:59

Re: GNU Pascal branch

Diego Novillo wrote:
> On 03/30/06 03:32, Adriaan van Os wrote:
> 
>> Still, I would like to create a GNU Pascal branch for gcc. This will be
>> a central place where to keep the compiler updated with
>>
> I don't think this is a good idea.  You are either part of the compiler
> or you aren't.  Front ends that are only partially incorporated will
> naturally suffer bit-rot and be largely ignored.  Even if the FE is not
> enabled by default, you can benefit from being integrated in the rest of
> the compiler (e.g., Ada).

Without making any judgement on the merits, adding GPC to the repository
would certainly need to be approved by the GCC SC.

--

-- 
Mark Mitchell
CodeSourcery
mark <at> codesourcery.com
(650) 331-3385 x713
Permalink | Reply | 0 comments |
headers
Rafael Espíndola | 1 Apr 2006 03:20
Picon

successfully removed the convert callback

The attached patch removes the convert callback by
1) copying the c implementation of convert to convert2
2) changing all calls to convert in gcj and gfortran into calls to convert2
3) adding a lang prefix to the remaining implementations (cxx_, c_, gnat_)
4) renaming all convert calls in a front end to the corresponding implementation
5) coping convert_and_check and constant_fits_type_p into the c++
front end so that it doesn't try to use convert2
6) renaming all the remaining calls to convert into convert2
7) removing the treelang, java and fortran implementation of convert

This patch was bootstraped and regtested on a x86 without any regressions!

I found a bit strange that there were no java regression since
convert_ieee_real_to_integer is no longer used. Is a testcase missing?

I will as soon as possible move item 5 into a patch of its on and
submit. I will then clean up the tons of dead code that I have added,
rename convert2 back to convert, move it to a better place,
reintroduce java_convert if needed and finally submit a patch.

I will be a bit busy, so I think that I will be able to do just the
first step during next week :-(

Best Regards,
Rafael
Attachment (convert.patch): text/x-patch, 242 KiB
Permalink | Reply | 2 comments |
headers
Rafael Espíndola | 1 Apr 2006 03:33
Picon

Re: Front end best practice in GCC 4.1.0?

> You know, I've always wondered why there wasn't a lisp-family front end
> for GCC, the roots of GNU and RMS being where they are (and didn't RMS
> promise way back when to make lisp suitable for unix systems
> programming?).  I'm just not connected enough to the lisp world to know
> the answer I guess.
I also don't know. We chose scheme because it was the only language we
knew of whose specification was small enough to read and still have
some time left to code in a semester :-)

> That's pretty much *exactly* what I had in mind--minimal front end that
> produces a useless, do-nothing, but "correct" front end.  Even the
> motivation is the same, since as you might expect this was a preface to
> a language project. :-)
Nice. If you notice, the documentation consists of a series of steps.
In the first one a front end that does nothing is created. In the
second step an empty main is generated. Unfortunately, even a hello
world front end is a bit hard to explain :-(

> I'd be happy to cooperate as much as possible.  The goal was to write
> the document I needed myself and didn't find, and in so doing learn the
> knowledge I'd have gotten from it.  It wasn't to write for writing's
> sake.  If you've done everything I wanted, so much the better. :-)
>
> That said, I haven't actually looked at your docs in detail.  It took me
> a while to install svn, figure out how to do a checkout and what URL to
> use, find the system docbook stylesheets, and put their path in the
> makefile (not too bad for someone who has never seen docbook or used XML
> before, I thought), and learn enough about docbook to find an
> alternative to fop (I am not eager to install it because I'm trying to
> keep this machine not-too-dependent on a jvm. :-) )
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ekkehard Morgenstern | 1 Apr 2006 09:38
Picon

Successfully built and installed GCC 4.0.3 on Slackware 10.2


I successfully built and installed GCC 4.0.3 on Slackware 10.2.

Bootstrapping info:

1. Output of srcdir/config.guess:

i686-pc-linux-gnu

2. Output of "gcc -v":

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-src/gcc-4.0.3/configure
Thread model: posix
gcc version 4.0.3

3. Distribution info for GNU/Linux:
Distribution: Slackware 10.2
Linux kernel: 2.6.16
glibc version: 1.x: libglib-1.2.so.0.0.10
           2.x: libglib-2.0.so.0.800.4

4. Info for people building GCC on the same configuration:
If you install to the default directory, which is /usr/local,
you either have to delete, rename or redirect the programs
in /usr/bin to /usr/local/bin. Also, you might want to link
/usr/include/c++/4.0.3 to /usr/local/include/c++/4.0.3.

5. Completeness of target-specific installation notes:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajath N R | 1 Apr 2006 15:28
Picon

Re: warning: initialization makes integer from pointer without a cast

On 3/29/06, Mike Stump <mrs <at> apple.com> wrote:
> On Mar 28, 2006, at 1:41 PM, Jack Howarth wrote:
> > I do have one other issue to resolve in this legacy c code which I
> > am unclear on.
>
> Wrong list.  This list is for the development of gcc, not other
> software.
>
> > warning: initialization makes integer from pointer without a cast
>
> Yup.
>
> > ...for the line with a NULL. My immediate inclination was to
> > substitute '0' for the NULL which does indeed eliminate the
> > warning.
>
> Ick.
>
> > Is there a more appropriate fix?
>
> int i = NULL;
>
> should be written as:
>
> int i = 0;
>
> but, I don't know why that wasn't obvious.
>

for this prepstruct bound_description {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ed Smith-Rowland | 1 Apr 2006 17:26
Picon
Gravatar

Re: GNU Pascal branch

All,

FWIW, I would like to add my support for creating a branch for gpc with 
the eventual goal
of integrating Pascal into mainline.  I would bootstrap and test this 
branch, report bugs and
do my best to help with solutions although I'm new at this.

I think both projects would benefit.  I'll venture some predictions:

GCC
1. Another language would test the middle and back ends more and expose 
more bugs.
    There would be the process, structure, and motivation to fix them 
because gpascal is integrated.
2. I know of one person from the gpc world who participates in gcc and 
understands the gcc-4+ internals.
    I'm sure more would follow.
3. It would be cool to have more languages!

--enable-languages=c,c++,java,objc,obj-c++,fortran,treelang,ada,pascal,   
Mwahahahah!!!
4. There are multi-language Pascal-C, etc systems that GCC would be left 
out of without gpascal.

GPC
1. The later versions of gcc are getting faster.  Moving gpc off of gcc-3
    and into gcc-4 would speed things up.  GCC-3.4.6 is the end of the 
line for GCC-3.
2. By targeting integration rather than proximity, all the recent work in
(Continue reading)

Permalink | Reply | 545 comments |
headers
gccadmin | 1 Apr 2006 19:51
Picon
Favicon

gcc-4.2-20060401 is now available

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

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 112606

You'll find:

gcc-4.2-20060401.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.2-20060401.tar.bz2         C front end and core compiler

gcc-ada-4.2-20060401.tar.bz2          Ada front end and runtime

gcc-fortran-4.2-20060401.tar.bz2      Fortran front end and runtime

gcc-g++-4.2-20060401.tar.bz2          C++ front end and runtime

gcc-java-4.2-20060401.tar.bz2         Java front end and runtime

gcc-objc-4.2-20060401.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.2-20060401.tar.bz2    The GCC testsuite

Diffs from 4.2-20060325 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Tromey | 1 Apr 2006 21:39
Picon
Favicon

Re: successfully removed the convert callback

>>>>> "Rafael" == Rafael Espíndola <rafael.espindola <at> gmail.com> writes:

Rafael> I found a bit strange that there were no java regression since
Rafael> convert_ieee_real_to_integer is no longer used. Is a testcase
Rafael> missing?

Did you run Jacks?  As I recall it has a test for this.

Tom
Permalink | Reply | 0 comments |
headers
Adriaan van Os | 1 Apr 2006 22:45
Picon
Favicon

Re: GNU Pascal branch

Ed Smith-Rowland wrote:

> All,
>
> FWIW, I would like to add my support for creating a branch for gpc  
> with the eventual goal
> of integrating Pascal into mainline.  I would bootstrap and test this  
> branch, report bugs and
> do my best to help with solutions although I'm new at this.
>
> I think both projects would benefit.  I'll venture some predictions:
>
> GCC
> 1. Another language would test the middle and back ends more and  
> expose more bugs.
>    There would be the process, structure, and motivation to fix them  
> because gpascal is integrated.
> 2. I know of one person from the gpc world who participates in gcc and  
> understands the gcc-4+ internals.
>    I'm sure more would follow.
> 3. It would be cool to have more languages!
>     
> --enable-languages=c,c++,java,objc,obj- 
> c++,fortran,treelang,ada,pascal,   Mwahahahah!!!

plus modula !

> 4. There are multi-language Pascal-C, etc systems that GCC would be  
> left out of without gpascal.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roger Sayle | 2 Apr 2006 05:19
Favicon

[RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop


Following some of my recent middle-end clean-ups, I believe that
we're now at the point where incrementally the middle-end can
start ignoring the TREE_OVERFLOW bits on constant tree nodes.
As a step in this direction, the patch below removes the
TREE_CONSTANT_OVERFLOW checks from integer_zerop, integer_onep,
and friends in tree.c.  This patch bootstraps and regression
tests on i686-pc-linux-gnu (including Ada) with no new failures.

The major true user of TREE_CONSTANT_OVERFLOW is the C front-end,
which doesn't use any of these functions to determine whether it
should issue a diagnostic when an overflowed integer is used in
a context requiring a compile-time constant.

Over the years, this overflow testing in the middle-end has caused
numerous bugs, the most recent being last week's PR26859.  Removing
this test cleans up the semantics of integer constants a little.
In the unlikely event that any problems are discovered, by routines
relying on these functions testing checking for overflow, the trivial
fix is to rewrite the callers as:

	if (integer_zerop (t)
	    && ! TREE_CONSTANT_OVERFLOW (t))
	  ...

There is now a stronger requirement on fold-const.c and friends that
it now be extra careful preserving TREE_CONSTANT_OVERFLOW for the
C front-end.  Optimizations such as "0 * x" -> "0" where we
test for zero using integer_zerop, have been checked to make sure
that we return the original zero, which the overflow bits set as
(Continue reading)

Permalink | Reply | 15 comments |

Gmane