GNU Pascal branch

[Adriaan van Os]

The GNU Pasal compiler  is maintained as a 
separate back-end project. The compiler can be built with gcc-2.8.1 up 
to gcc-3.4.x and preliminary support for gcc-4.0 was recently added 
(). A regular 
question is why gpc isn't integrated into the gcc repository. The 
answer is that simply the resources fail to maintain gpc on a daily 
basis on gcc mainline. Also, flexibility in choosing the back-end 
version sometimes has its advantages, dependent on the platform, given 
the fact that reported gcc bugs are not always fixed.


Apropos,  seems to be pointing to the 
wrong page now.


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


* recent gpc snapshots
* patches to the front-end, posted on the GNU Pascal mailing list 
 (to add features or to fix 
bugs)
* patches to the back-end and middle-end, needed to get things working 
for various targets.


 explains how to create a 
branch, so I am looking for a gcc maintainer to approve for write 
access (solely for the branch). I signed an FSF assignment for the GNU 
Pascal compiler on February 15, 2005 (OS/RT 220644).


Sincerely,

Adriaan van Os

Re: GNU Pascal branch

[Adriaan van Os]

The GNU Pasal compiler  is maintained as a 
separate back-end project. The compiler can be built with gcc-2.8.1 up 
to gcc-3.4.x and preliminary support for gcc-4.0 was recently added 
(). A 
regular question is why gpc isn't integrated into the gcc repository. 
The answer is that simply the resources fail to maintain gpc on a 
daily basis on gcc mainline. Also, flexibility in choosing the 
back-end version sometimes has its advantages, dependent on the 
platform, given the fact that reported gcc bugs are not always fixed.


Apropos,  seems to be pointing to 
the wrong page now.


Sorry, it isn't, I mixed up "front-end" and "back-end".

Sincerely,

Adriaan van Os

Re: gcc project

[Diego Novillo]

On 03/29/06 16:05, Nic Volanschi wrote:

> Nevertheless, this light approach could be combined with the API-based
> approach, by complementing the (declarative) code patterns with
> (executable) predicates using the API, and loaded as dynamic libraries. 
> 
Yes, absolutely.  Once you have a pluggable interface, you can add more
abstractions on top of it.

> Ok, I'll take a few days to install subversion, figure how to use it,
> port my stuff to the current 4.2 mainline, etc, and I'll get back. Note
> that I'm doing everything on my spare time, so it's not that predictable
> :°).
> 
Before you do that, however, you may need to do some paperwork.  Do you
have an FSF copyright assignment on file?  If not, you will need to go
through that process before we can accept your contribution.  Thanks.

Re: Ada subtypes and base types

[Duncan Sands]

On Wednesday 29 March 2006 23:28, Tom Tromey wrote:
> > "Duncan" == Duncan Sands <[EMAIL PROTECTED]> writes:
> 
> Duncan> That still leaves the problem of how the Ada front-end tells the
> Duncan> middle-end that a variable is known to be in a certain range.  Due
> Duncan> to the way the language works, the front-end often does know a useful
> Duncan> range, helpful for optimisation.  If using types with strange ranges
> Duncan> is out, and ASSERT_EXPRs aren't appropriate, what is left?
> 
> Yeah, there's got to be something.
> 
> On irc today we were discussing handling 'this' in gcj.  We can add an
> attribute to the argument to mark it as non-null... but strangely
> there doesn't seem to be a way to mark other local variables as
> known-non-null -- a curious deficiency.

If the front-end was allowed to place ASSERT_EXPRs in the trees it passes
to the middle-end, then you could place such assertions on the appropriate
local variables and voila.  Jeff claimed that this would cause serious
problems for the copy propagation pass, but I don't see why.

All the best,

Duncan.

undefined declaration in pre-processed generated C file

[GALLEGGIANTI Bruno]

Hi,

My name is Bruno Galleggianti and I am working for the CEA, a French 
Research centre.

I use gcc 3.3.2 and I work on generated pre-processed C files.

In example, I'm using classic 'helloworld' source file.
In this file, I include  header and this header file includes
 header file.
In the generated pre-processed C file, I've detected at line 9 of
helloworld.i file (see attached files) the following declaration
(resulting of the inclusion of stdarg.h file!):

typedef __builtin_va_list __gnu_va_list;

My problem is that __builtin_va_list is never declared/defined in the
pre-processed file. I've no warning about that (-Wall option)

Following this behaviour, I have 3 questions:

1) How does gcc compiler resolve this typedef (before link stage) ?

2) Is there a gcc option that can remove this type of definition in
pre-processed files? I think it's not possible before link stage.

3) Is there a possibility to obtain pre-processed C source file after
link phase (without optimization)?

Thank you for your help

Regards

Bruno Galleggianti


helloworld.c
Description: helloworld.c


helloworld.i
Description: helloworld.i

RE: undefined declaration in pre-processed generated C file

[Dave Korn]

On 30 March 2006 13:52, GALLEGGIANTI Bruno wrote:

> typedef __builtin_va_list __gnu_va_list;
> 
> My problem is that __builtin_va_list is never declared/defined in the
> pre-processed file. I've no warning about that (-Wall option)
> 
> Following this behaviour, I have 3 questions:
> 
> 1) How does gcc compiler resolve this typedef (before link stage) ?

  It's magic.  Gcc knows about all builtins automatically because they are
implemented in code inside the compiler.  For more details about how stdargs
work, run "info gccint" and browse the section about "Implementing the Varargs
Macros".  If you're really curious, the __builtin_va_list struct is (IIRC)
generally the same struct as whatever the backend defines as CUMULATIVE_ARGS -
read the info page about "Passing Arguments in Registers".

> 2) Is there a gcc option that can remove this type of definition in
> pre-processed files? I think it's not possible before link stage.

  Would "grep -v 'typedef __builtin' newsourcefile.i" do the
job you're after?

  The real question 
 
> 3) Is there a possibility to obtain pre-processed C source file after
> link phase (without optimization)?

  Nope, that doesn't make sense; first, by link time, the C has already been
turned into assembler long ago; second, optimisation is not applied to the C
source but to the internal representation.

  What are you /actually/ trying to do?

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: undefined declaration in pre-processed generated C file

[Neil Booth]

GALLEGGIANTI Bruno wrote:-

> typedef __builtin_va_list __gnu_va_list;
> 
> My problem is that __builtin_va_list is never declared/defined in the
> pre-processed file. I've no warning about that (-Wall option)
> 
> Following this behaviour, I have 3 questions:
> 
> 1) How does gcc compiler resolve this typedef (before link stage) ?

__builtin_va_list is, as described, built-in to the compiler.  It is
not defined anywhere; it's built-in definition may well be target-
specific.

You will always have this problem operating on preprocessed source.
Other compilers have similar built-in definitions, such as
__NAN__.  Preprocessed source is compiler-specific.

Neil.

Re: Ada subtypes and base types

[Diego Novillo]

On 03/30/06 07:24, Duncan Sands wrote:
> On Wednesday 29 March 2006 23:28, Tom Tromey wrote:
>
>> On irc today we were discussing handling 'this' in gcj.  We can add an
>> attribute to the argument to mark it as non-null... but strangely
>> there doesn't seem to be a way to mark other local variables as
>> known-non-null -- a curious deficiency.
> 
> If the front-end was allowed to place ASSERT_EXPRs in the trees it passes
> to the middle-end, then you could place such assertions on the appropriate
> local variables and voila.  Jeff claimed that this would cause serious
> problems for the copy propagation pass, but I don't see why.
> 
When I initially implemented VRP, I was adding assertions very early in
the compilation pipeline.  This has the advantage of getting the SSA
form on assertions built "for free".

However, it has negative effects on passes that rely on equality
properties like copy-propagation, value numbering, etc.  So, not only
you need to "fix" every pass to see through ASSERT_EXPRs, you pay a
compile time penalty for doing so.

My recommendation is to first try and use langhooks that you can then
query in the assert insertion phase in tree-vrp.c.

In fact, ISTR something along these lines that Anthony Green added as a
proof of concept sometime last year.  Anthony?  Do you remember what it was?

GCC 3.3.6 built OK for HP-UX 11.11

[Andreas Garvik]

Hi,

1. config.guess:

hppa2.0w-hp-hpux11.11

2. gcc -v

macallan 253: gcc -v
Reading specs from
/lts_dev/opt/hp-gcc/3.3.6/ilp32/lib/gcc-lib/hppa1.1-hp-hpux11.11/3.3.6/specs
Configured with: /proj/oscp/nightly/gcc/gcc_3_3_6_release/gcc/configure
--enable-languages=c,c++ --enable-threads=posix 
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --build=hppa1.1-hp-hpux11.11
--host=hppa1.1-hp-hpux11.11 --target=hppa1.1-hp-hpux11.11 
--prefix=/opt/hp-gcc/3.3.6/ilp32
--with-as=/proj/oscp/nightly/gcc/gcc_3_3_6_release/HP-UX/hppa//opt/hp-gcc/3.
3.6/ilp32/bin/as
Thread model: posix
gcc version 3.3.6
macallan 254: pwd
/lts_dev/gcc_3.3.6_DL/GCC_Posix_336_obj/bin
macallan 255:


3. uname -a

HP-UX macallan B.11.11 U 9000/800 1770927651 unlimited-user license

4. --enable-languages=c,c++  (Only built for C,C++, package core and g++
downloaded).

Built on a HP RP5430 server. 

I had to configure the libstdc++-v3 separately prior to the build,
i.e. make sure to run the configure command for libstdc++-v3 as well. 

I have also built it for single thread, i.e. --enable-threads=single. 
For posix thread --enable-threads=posix you will need
libpthread* in your /usr/lib.

I also installed libiconv 1.10 prior to the build.

With this setup, I am able to have the GCC 3.3.6 and 2.95.2 on the 
same machine, and toggling between them is easy with logical links. 

Thanks,
Andreas Garvik 

Re: GCC 4.1.0 build error (as doesn't like code produced by xgcc)

[Clifford Wolf]

Hi,

On Wed, Mar 29, 2006 at 09:31:26AM -0500, Daniel Jacobowitz wrote:
> On Tue, Mar 28, 2006 at 03:10:30PM +0200, Clifford Wolf wrote:
> >   /tmp/cc9Aywrx.s: Assembler messages:
> >   /tmp/cc9Aywrx.s:1256: Error: can't resolve `.text.unlikely' 
> > {.text.unlikely section} - `.LCFI70' {.text section}
> 
> The assembly is wrong.  File a GCC bug.  Two subtracted symbols should
> generally be in the same section.

bug filed:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26942

yours,
 - clifford

-- 
 _  _   _  Nerds on Air - Radio for Geeks  _  __ ___
| \| |___  /_\   On 1st and 3rd Friday of the month   / |/ /__  / _ |
| .` / _ \/ _ \21:00-22:00 CET on Radio Orange   // _ \/ __ |
|_|\_\___/_/ \_\ http://www.clifford.at/noa//_/|_/\___/_/ |_|
 
[..] If it still doesn't work, re-write it in assembler. This won't fix the
bug, but it will make sure no one else finds it and makes you look bad.
 

Re: Lot's of ICEs with Polyhedron and -ftree-vectorize with mainline

[Richard Guenther]

On Wed, 29 Mar 2006, Richard Guenther wrote:

> 
> Has anyone gone through Polyhedron ICEs with -ftree-vectorize?  I see
> aermod, air, doduc, linpk, mdbx, rnflow and test_fpu ICE on i686 and
> additionally induct and tfft on x86_64.  (-O3 -ffast-math -funroll-loops
> otherwise)

After the fix for the bogus VEC_* transition for dda, we're back to
induct ICEing on x86_64 and air, doduc and mdbx ICEing on i686.  I won't
have time to analyze any of those in the near time though.

Richard.

Re: Incremental gcc

[Camm Maguire]

Greetings, and thanks for your reply!


Mike Stump <[EMAIL PROTECTED]> writes:

> On Mar 25, 2006, at 9:14 PM, Camm Maguire wrote:
> > Greetings! GCL is a lisp compiler system which outputs C code normally
> > compiled by gcc into an object, which is then loaded and relocated
> > into the running GCL image.  In lisp, compiling is a very incremental
> > process, with many, often thousands of small functions compiled one at
> > a time.  GCL/gcc compilation speed would be greatly improved if gcc
> > could be run in some sort of incremental mode
> 
> Ignoring an ideal world for a second, if you have large amounts of  headers 
> that are stable that are needed for compilation, be sure to
> precompile them.  After that, batch up all code to be compiled into  larger 
> unit and compile it all in one go, as it saves a substantial

Thanks!  We've done this just recently to some benefit.

> amount of time (2x faster maybe), this way startup costs are amortized.
> 

This is often impossible to arrange at the compiler level in lisp.

> Longer term, it would be nice to have someone from your camp layout  where 
> the time is spent and what changes might be worth while in gcc  to
> make it more suitable for that type of work.

This would be interesting, how does one benchmark gcc performance in
this way?


> 
> You can run the compiler via stdin and stdout:
> 
> $ gcc -x c - -o - -S
> int i;
> main() { }
> ^D  .section __TEXT,__text,regular,pure_instructions
>  .section  __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32
>  .machine ppc
>  .text
>  .align 2
>  .globl _main
> _main:
>  stmw r30,-8(r1)
>  stwu r1,-48(r1)
>  mr r30,r1
>  lwz r1,0(r1)
>  lmw r30,-8(r1)
>  blr
> .comm _i,4
>  .subsections_via_symbols
> 
> if you want, so that isn't very hard to do.  The sub-problem of an as  that 
> can operate this way is off-topic for this list, so I won't

This was the most promising.  If I could run gcc as a pipe with
assembler only output, all I need is a 'flush instruction on stdin to
get the assemly of the function(s) input thus far.  Then the pipe
should be ready for another function definition followed by a flush,
etc.  Is there such?

> address it.

The assembly problem is different, as you state.  Among other reasons,
the output must be seekable as it is bfd based.  Coincidentally, GCL's
binary input is bfd based, so it should be possible to incorporate the
assembler and leave the output in memory.

> 
> Long term, might be nice to have a way to wire in the assemblers into  gcc 
> directly.  If you guys feel ambitious, that might be doable; but
> since gc is driven by people that want to code, you'll have to find  someone 
> that wants to code it up.  The java folks might be interested
> in JITifying the compiler as well, if enough people are interested in  doing 
> that, it might be an interesting direction to take gcc, though
> building in as strikes me as a prerequisite.
> 

Thanks again.  There is interest, but it might be a ways off before
sufficient time becomes available.

Take care,

> 
> 

-- 
Camm Maguire[EMAIL PROTECTED]
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: GNU Pascal branch

[Steven Bosscher]

On 3/30/06, Adriaan van Os <[EMAIL PROTECTED]> wrote:
> The
> answer is that simply the resources fail to maintain gpc on a daily
> basis on gcc mainline.

It seems to me that integrating gpc would _reduce_ the burden on the
gpc team, because you would get more regular testing and people are
responsible for fixing all front ends when they do backend changes.
The gpc folks would only have to worry about the front end.

> Also, flexibility in choosing the back-end
> version sometimes has its advantages, dependent on the platform, given
> the fact that reported gcc bugs are not always fixed.

So you could help fix them, instead of forcing people to stick to
older backends ;-)

> 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

What would be the benefits of this for GCC? Wouldn't this just result
in more bug reports for GCC maintainers about a project that they have
no control over?  If you don't plan to integrate gpc with the rest of
GCC, then I don't see any reason why gpc would have to live in the GCC
subversion repository.  Just my $0.02...

Gr.
Steven

Re: the loss of SET_TYPE

[Gaius Mulley]

"Steven Bosscher" <[EMAIL PROTECTED]> writes:

> Does the code conform to the GNU/GCC coding conventions? You can find
> those on the gcc web site (http://gcc.gnu.org/codingconventions.html).

Hi,

thanks for the URL.

Generally yes - although the documentation needs more work to include
internal front end details (gm2 as of gcc-3.3.6 graft needed no tree
extensions).  The later graft will define its own tree.def to
implement SET_TYPE as previously advised etc. All gm2 command line
switches are documented in gm2/gm2.texinfo.

It would be good to restructure some of the gm2-gcc interface code,
into similar filenames to that used by other front ends. Ie
m2typeck.c, m2decl.c rather than the large single file gm2/gccgm2.c.
There is quiet a bit of pseudo duplication between gm2 and say the C
front end - it would be really good to reduce this if possible..

Regressions tests and ChangeLog entries have been coordinated for some
time now. Although they could adopt a more formal PR numbering scheme
as per gcc.

regards,
Gaius

Re: GNU Pascal branch

[Diego Novillo]

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).

If you were to integrate the gpc FE with the rest of the compiler, then
you would only need to worry about FE bugs.  The ME and BE bugs exposed
by your front end would then be treated as first class citizens in our
bug database.

>  explains how to create a
> branch, so I am looking for a gcc maintainer to approve for write access
> (solely for the branch). I signed an FSF assignment for the GNU Pascal
> compiler on February 15, 2005 (OS/RT 220644).
> 
If you have an FSF assignment then it's only a matter of filling in the
SVN access form.  You can use my address as reference in the form.  Then
it's just a matter of posting the back-end and front-end patches to
gcc-patches.

If the BE patches are not specific to gpc and fix bugs reproducible with
other FEs, we could even consider adding them to mainline.

But first, you have to decide whether you want to integrate with the
rest of the compiler or not.  Halfway integration will be a waste of
everybody's time.

Re: GNU Pascal branch

[Adriaan van Os]

Steven Bosscher wrote:


Adriaan van Os <[EMAIL PROTECTED]> wrote:

The
answer is that simply the resources fail to maintain gpc on a daily
basis on gcc mainline.


It seems to me that integrating gpc would _reduce_ the burden on the
gpc team, because you would get more regular testing


the problem is not regular testing.


and people are
responsible for fixing all front ends when they do backend changes.


I don't believe that, they would just say, "oh, it is broken" or "oh, 
it is not a primary language" or whatever excuse.



The gpc folks would only have to worry about the front end.


Also, flexibility in choosing the back-end
version sometimes has its advantages, dependent on the platform, given
the fact that reported gcc bugs are not always fixed.


So you could help fix them, instead of forcing people to stick to
older backends ;-)


We are not forcing anybody, we offer full choice. Not fixing 
backend-end bugs is what is actually forcing people. And even patches 
that do fix bugs are often not accepted.


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


What would be the benefits of this for GCC? Wouldn't this just result
in more bug reports for GCC maintainers


No.


about a project that they have
no control over?  If you don't plan to integrate gpc with the rest of
GCC, then I don't see any reason why gpc would have to live in the GCC
subversion repository.


Thanks for your great cooperation.

Adriaan van Os

Re: GNU Pascal branch

[Andrew Haley]

Adriaan van Os writes:
 > Steven Bosscher wrote:
 > 
 > > Adriaan van Os <[EMAIL PROTECTED]> wrote:
 > >> The
 > >> answer is that simply the resources fail to maintain gpc on a daily
 > >> basis on gcc mainline.
 > >
 > > It seems to me that integrating gpc would _reduce_ the burden on the
 > > gpc team, because you would get more regular testing
 > 
 > the problem is not regular testing.
 > 
 > > and people are
 > > responsible for fixing all front ends when they do backend changes.
 > 
 > I don't believe that, they would just say, "oh, it is broken" or "oh, 
 > it is not a primary language" or whatever excuse.
 > 
 > > The gpc folks would only have to worry about the front end.
 > >
 > >> Also, flexibility in choosing the back-end
 > >> version sometimes has its advantages, dependent on the platform, given
 > >> the fact that reported gcc bugs are not always fixed.
 > >
 > > So you could help fix them, instead of forcing people to stick to
 > > older backends ;-)
 > 
 > We are not forcing anybody, we offer full choice. Not fixing 
 > backend-end bugs is what is actually forcing people. And even patches 
 > that do fix bugs are often not accepted.

As another maintainer of a "minority" language, I have to say that the
situation is not as bad as you suggest.  Although occasional conflicts
do occur, they generally get fixed, and other maintainers help us too.
It's better to be inside than out.

Andrew.

Re: Ada subtypes and base types

[Jeffrey A Law]

On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:

> On irc today we were discussing handling 'this' in gcj.  We can add an
> attribute to the argument to mark it as non-null... but strangely
> there doesn't seem to be a way to mark other local variables as
> known-non-null -- a curious deficiency.
It seems to me that for other locals that the non-null property
ought to be a property of how those locals are assigned a value.
ie, if we're going to be able to derive a non-null for a local we
should be able to derive it from the RHS of the assignment(s) to
that local.


IIRC "this" is actually a parameter and thus there's no assignment
we can derive information from.

jeff

Re: Ada subtypes and base types

[Andrew Haley]

Jeffrey A Law writes:
 > On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
 > 
 > > On irc today we were discussing handling 'this' in gcj.  We can add an
 > > attribute to the argument to mark it as non-null... but strangely
 > > there doesn't seem to be a way to mark other local variables as
 > > known-non-null -- a curious deficiency.
 > It seems to me that for other locals that the non-null property
 > ought to be a property of how those locals are assigned a value.
 > ie, if we're going to be able to derive a non-null for a local we
 > should be able to derive it from the RHS of the assignment(s) to
 > that local.

Right, that's true.  The idea is that a great many library functions
either return a valid object or throw an execption, and we can
propagate that information to VRP>

 > IIRC "this" is actually a parameter and thus there's no assignment
 > we can derive information from.

Mmm, yeah.  The point is that we solved the problem for "this", but
not for other things.

Andrew.

Re: Ada subtypes and base types

[Jeffrey A Law]

On Tue, 2006-03-28 at 23:49 +0200, Duncan Sands wrote:

> That still leaves the problem of how the Ada front-end tells the
> middle-end that a variable is known to be in a certain range.  Due
> to the way the language works, the front-end often does know a useful
> range, helpful for optimisation.  If using types with strange ranges
> is out, and ASSERT_EXPRs aren't appropriate, what is left?  After
> further thought, I'm not so against the use of these ranges as I was...
As I've stated before, I really don't think that we're gaining that
much from those front-end ranges and the way the front-ends are
generating code is likely getting in the way of more useful 
optimizations.

I haven't thought a whole lot about how to get the benefit of those
ranges without the penalties.  The only guidelines I can immediately
come up with are to not expose the subtypes to the optimizers except
for VRP.  ie, do *everything* in the base type and not emit all the
conversions between the base and sub types, then have some way for
VRP to query objects for subtype range information.

> I'm playing with the code right now, getting rid of VR_VARYING.  Do
> you have any suggestions for benchmarking it?
Most of us have a bucket of .i and .ii files that we use for compile
time testing.  You might even be able find a tarball of such files
on Diego's home page IIRC.

You might consider running those benchmarks with a compiler that
has enable-checking turned off.  You're not interested in the
checking bits and they'll just make it harder to find/interpret
any interesting results from your tests.


jeff

Re: Ada subtypes and base types

[Jeffrey A Law]

On Thu, 2006-03-30 at 18:39 +0100, Andrew Haley wrote:
> Jeffrey A Law writes:
>  > On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote:
>  > 
>  > > On irc today we were discussing handling 'this' in gcj.  We can add an
>  > > attribute to the argument to mark it as non-null... but strangely
>  > > there doesn't seem to be a way to mark other local variables as
>  > > known-non-null -- a curious deficiency.
>  > It seems to me that for other locals that the non-null property
>  > ought to be a property of how those locals are assigned a value.
>  > ie, if we're going to be able to derive a non-null for a local we
>  > should be able to derive it from the RHS of the assignment(s) to
>  > that local.
> 
> Right, that's true.  The idea is that a great many library functions
> either return a valid object or throw an execption, and we can
> propagate that information to VRP>
> 
>  > IIRC "this" is actually a parameter and thus there's no assignment
>  > we can derive information from.
> 
> Mmm, yeah.  The point is that we solved the problem for "this", but
> not for other things.
And I think the way to solve this is to mark those interesting
library functions, then fix VRP so that it's not so eager to ignore
function calls :-)

jeff
> 
> Andrew.

Re: Ada subtypes and base types

[Tom Tromey]

> "Jeff" == Jeffrey A Law <[EMAIL PROTECTED]> writes:

Jeff> It seems to me that for other locals that the non-null property
Jeff> ought to be a property of how those locals are assigned a value.

Yeah, thanks for the re-frame.  This is PR 20318, and also related to
PR 21856.

Tom

Re: R_PPC_REL24 overflow

[Richard Henderson]

On Wed, Mar 29, 2006 at 04:51:59PM -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 29, 2006 at 01:53:31PM -0500, James Lemke wrote:
> > The generated asm makes the reference as:
> > bl [EMAIL PROTECTED]  # 141  *call_value_nonlocal_sysv/1 [length = 4]
> > 
> > And for this, gas generates:
> > R_PPC_REL24  __pthread_mutex_lock
> > 
> > Can anyone help clarify what is / should be going on here?
> 
> All fine so far.

Um, no?  R_PPC_PLTREL24 should be used.


r~

ANNOUNCE: GCC track at Gelato ICE finalized - April 24 & 25

[Mark K. Smith]

The following GCC track is part of the Gelato ICE (Itanium Conference
& Expo) technical program. All interested GCC developers are invited
to attend . A complete list of speakers and
topics can be found here: 

Monday Afternoon (4/24/06):
* 2:15 pm - Arutyun Avetisyan
  The ISP RAS Effort to Improve GCC for Itanium
  August '06 GCC meeting in Moscow
* 3:00 pm - Dan Berlin
  GCC IP issues
* 4:15 pm - Shin-Ming Liu
  An ORC Backend for GCC
* 5:00 pm - Cameron McNairy 
  Itanium 2 and Montecito Microarchitecture

Monday Night (4/24/06):
* 7:00 pm - Dan Berlin
  Aliasing in GCC
* 7:30 pm - Bob Kidd 
  Superblock Update
* 8:00 pm - Andrey Belevantsev
  An Interblock VLIW Targeted Instruction Scheduler for GCC  
* 8:30 pm - Diego Novillo 
  Parallel programming with GCC

Tuesday Afternoon (4/25/06):
* 2:30 pm - Mark Mitchell
  LTO: A Brief Introduction
* 3:30 pm - Chris Lattner
  LLVM: A Brief Introduction
  

Paperwork to contribute to GCC

[Rafael Dantas de Castro]

Hi,

   I'd like to contribute some code to GCC, specifically a "Hello
World" frontend for GCC4, we built as part of an University project on
compilers . I was wondering about the paperwork I'd have to fill out.
Is this the right place to e-mail? Who could send that to me? I don't
sign the mailing list, so I'd appreciate if someone could send me a
personal response...


thanks in advance,

--
Rafael Dantas de Castro
Mestrando em Computação 2006 - Unicamp
 - Laboratório de Criptografia Aplicada

"Se procurar bem você acaba encontrando.
 Não a explicação (duvidosa) da vida,
 Mas a poesia (inexplicável) da vida."

   Carlos Drummond de Andrade

transient bug in gcc

[Virgil Anderson]

>From time to time i run into these ridiculous bugs in gcc which make me
want to choke it!
Here is another ... in gcc-4.1.0
This is according to the web a much reported problem from apparently way
way back ... maybe 5 or more years.  In gcc/crtstuff.c there is an
include which is local tsystem.h which drags in a whole series of system
includes For whatever reason gcc insists the system includes are not
present ... no mater that every other program and configure found them,
 is among them.  There is a bit of pre-process logic which
has something to do with libc and bootstrapping which looks hokie, but
whatever.  The problem seems
to happen inside this code... however to get around the problem when
building in /usr  you have to do
ln -s /usr/include /usr/local/include and once you figure that out -- it
is on the web in multiple places for various projects compiling the
compiler works fine... at least sort of...
The question I have is why are these issues never seriously fixed?  The
solution is anything but obvious, however this is too hokie to just
happen.  It must have something to do with a limit on the number of open
file handles in a search path somewhere, or it would never work to ad in
a link to something which is already known, in a path which is a
secondary search.

Virgil Anderson
[EMAIL PROTECTED]

Re: Incremental gcc

[Mike Stump]

On Mar 30, 2006, at 7:55 AM, Camm Maguire wrote:
Longer term, it would be nice to have someone from your camp  
layout  where the time is spent and what changes might be worth  
while in gcc to make it more suitable for that type of work.


This would be interesting, how does one benchmark gcc performance  
in this way?


Well, the types of things I had in mind include things like relaying  
out the compiler so that the startup costs are reduced, if those  
costs impact you to a greater extent than others, deciding which  
optimizations are too expensive for the types of code you put through  
the compiler, and turning them off (or throttling them down or moving  
them out to O3) or even pulling in some from O2, maybe having a  
special compiler that excludes some of the unneeded optimizations to  
reduce the memory footprint.  One way to think of this would be -Ojit  
and then tune that to turn on and off all the various things.  There  
are many possibilities that come to mind, and I wouldn't presume to  
know just what types of tweaks would be best.


As to how to go about tuning it, that doesn't have a 1 paragraph  
answer.  Startup costs are easy enough, gcov or Shark an empty  
program and then examine all the large numbers and see if there is a  
way to move those items to compiler build time.  For other costs,  
examine gcc against an existing good JIT system and try and figure  
out where the time is going and ways to reduce it.  Having a JIT  
expert examine gcc would probably be the way to go.


This was the most promising.  If I could run gcc as a pipe with  
assembler only output, all I need is a 'flush instruction on stdin  
to get the assemly of the function(s) input thus far.


I suspect we could add a fflush after each function...  I don't think  
we presently do.

Re: Incremental gcc

[Richard Guenther]

On 3/31/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Mar 30, 2006, at 7:55 AM, Camm Maguire wrote:
> > This was the most promising.  If I could run gcc as a pipe with
> > assembler only output, all I need is a 'flush instruction on stdin
> > to get the assemly of the function(s) input thus far.
>
> I suspect we could add a fflush after each function...  I don't think
> we presently do.

This won't work gcc needs to see the whole compilation unit.

Richard.

gcc-4.0-20060330 is now available

[gccadmin]

Snapshot gcc-4.0-20060330 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060330/
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 112546

You'll find:

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

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

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

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

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

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

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

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

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

RFC: Branch for define_constraint conversions

[Zack Weinberg]

Since mainline is now in bugfixes only mode, and since port conversions
have been being more troublesome than I had hoped, I think it makes sense
to start a branch now to queue up port conversions until the next release
cycle.  I can undertake to do periodic mainline-to-branch merges (no more
frequently than once a week) and in the interest of easy landing once the
next cycle opens, perhaps patches going onto the branch should be reviewed
in advance, using Stage 2 rules.

In addition, possibly we could get started on all the machine-independent
improvements that were promised for after all ports were converted.  The
upside of this would be that said improvements would get implemented
sooner, and people could see the benefits for themselves.  The downside
would be that it would break all unconverted ports on the branch, thus
potentially making conversions harder, and it would mean that we *had* to
get all ports converted before the branch could land.

I'm interested in any and all thoughts on the topic.  I'll be out of touch
from now until Sunday, but my inbox is large. :)

zw

Re: R_PPC_REL24 overflow

[Alan Modra]

On Wed, Mar 29, 2006 at 01:53:31PM -0500, James Lemke wrote:
> The generated asm makes the reference as:
> bl [EMAIL PROTECTED]  # 141  *call_value_nonlocal_sysv/1 [length = 4]
> 
> And for this, gas generates:
> R_PPC_REL24  __pthread_mutex_lock

Nope, you're looking at the wrong asm.  unlock vs. lock (and underscore
difference too).  As rth said, you need R_PPC_PLTREL24.  My guess is
that you have some buggy asm somewhere lacking @plt on the call.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Qemu and GCC-3.4 on powerpc

[Alan Modra]

On Tue, Mar 28, 2006 at 12:00:47PM +0200, Gabriel Paubert wrote:
> On Tue, Mar 28, 2006 at 12:56:13AM +0200, Dieter Schuster wrote:
> > If I try to compile qemu with GCC 3.4 without the patch I get the following 
> > error:
> > 
> > qemu-0.8.0/linux-user/elfload.c: In function `load_elf_binary':
> > qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an 
> > `asm'
> > qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an 
> > `asm'
> 
> Weird. CC'ed to gcc list despite the fact that the 3.4 branch
> is definitely closed. I've not found anything remotely similar
> from bugzilla.
> 
> > 
> > But if I copy the function stl_le_p to a seperate file, the function
> > will compile with GCC 3.4. 

Check preprocessor output.  My guess is that you have some unexpected
substitution.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Segment registers support for i386

[Rémy Saissy]

Hi everybody,
I'm looking for gcc support of x86-32 segment registers but the only information
I've found about it is in this old thread:
http://gcc.gnu.org/ml/gcc/1999-12/msg00526.html
I was wondering what happened since this thread, does somebody have integrated
the segment register support for i386 in gcc ?
There is nothing about it in the manual pages and gcc 4.0.3 doesn't
seem to support it.
Thank for your precisions.
Have a great day.


--
Rémy SaissyJabberID: [EMAIL PROTECTED]
Web: http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.

RE: undefined declaration in pre-processed generated C file

[GALLEGGIANTI Bruno]

In fact, I'm working on the development of a concept validation tools, based on 
the source code (static approach).
I use a parser to read the pre-processed files, but I've found problem due to 
the __builtin_* declarations.

I though about grep action on preprocessed file, but this solution isn't 
completely agree with some cases that I encountered: I have the case where this 
type is used (such as in vsnprintf function).
But I think to have another solution that will work with my problematic.

I need to realize more tests to see all special cases like builtin case.

Thank you for your fast answer. It will help me for my development.

Bye.

Bruno.

-Message d'origine-
De : Dave Korn [mailto:[EMAIL PROTECTED] 
Envoyé : jeudi 30 mars 2006 15:14
À : GALLEGGIANTI Bruno; gcc@gcc.gnu.org
Objet : RE: undefined declaration in pre-processed generated C file

On 30 March 2006 13:52, GALLEGGIANTI Bruno wrote:

> typedef __builtin_va_list __gnu_va_list;
> 
> My problem is that __builtin_va_list is never declared/defined in the
> pre-processed file. I've no warning about that (-Wall option)
> 
> Following this behaviour, I have 3 questions:
> 
> 1) How does gcc compiler resolve this typedef (before link stage) ?

  It's magic.  Gcc knows about all builtins automatically because they are
implemented in code inside the compiler.  For more details about how stdargs
work, run "info gccint" and browse the section about "Implementing the Varargs
Macros".  If you're really curious, the __builtin_va_list struct is (IIRC)
generally the same struct as whatever the backend defines as CUMULATIVE_ARGS -
read the info page about "Passing Arguments in Registers".

> 2) Is there a gcc option that can remove this type of definition in
> pre-processed files? I think it's not possible before link stage.

  Would "grep -v 'typedef __builtin' newsourcefile.i" do the
job you're after?

  The real question 
 
> 3) Is there a possibility to obtain pre-processed C source file after
> link phase (without optimization)?

  Nope, that doesn't make sense; first, by link time, the C has already been
turned into assembler long ago; second, optimisation is not applied to the C
source but to the internal representation.

  What are you /actually/ trying to do?

cheers,
  DaveK
-- 
Can't think of a witty .sigline today