Re: x86-64 and large code model questions/bugs

[Paolo Bonzini]

> He'll get much better code by putting the program into a -fPIC .so,
> loading it from a small stub and then unmap the stub.
> large model generates really very bad code because all jumps
> will be indirect.

Is it also true with -fpie?

Paolo

Re: Serious code generation/optimisation bug (I think)

[Robert Dewar]

Chris Lattner wrote:


It will be quite a while before whole program optimization is good
enough to prove that my_null_pointer is not referenced by anything
else.


Why not just make it volatile, that way, the compiler cannot assume
anything about the value.

Re: Request for testing/help for the LTO branch

[Rafael Espindola]

> Hi Diego,
>
> Thanks for the summary, it's great to see the progress of the project.  Do
> you have any compile time numbers for LTO so far?  If you pick a mid-sided
> program from spec or even a bootstrap, how much slower is LTO than compiling
> at -O3?

We haven't tried a bootstrap with LTO enabled yet (needs some changes
to the build system to find the gold plugin during bootstrap). We
should probably try -flto-single one day...

Some initial testing with internal apps showed that the streamer is
normally a problem and in some cases the performance is IO bound! This
is very true if the streamer debug is enabled, since that adds some
fairly large synchronization strings to the output.

Cary wrote a patch to gold to ignore IL sections if not using the
plugin, and it had a noticeable impact..

Diego, you tested SPEC a bit, do you know what the slowdown was?

> -Chris
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: x86-64 and large code model questions/bugs

[Andi Kleen]

On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
> 
> > He'll get much better code by putting the program into a -fPIC .so,
> > loading it from a small stub and then unmap the stub.
> > large model generates really very bad code because all jumps
> > will be indirect.
> 
> Is it also true with -fpie?

Not sure what you mean?

AFAIK -fpie code is the same quality as -fPIC. Both
are much much better than large model.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: gcc-4.3.3 bootstrap fails on old Sun Sparc

[Andreas Schwab]

Dennis Clarke  writes:

> One of the things I have had no joy with is figuring out how to
> include the ada component but that is a battle for another day.

To build ada you need a good ada compiler to start with.  If you don't
have one natively you need to build a cross compiler on a system that
has one and then build the native ada compiler with this cross
compiler.  Then you can rebootstrap with ada enabled.

Andreas.

-- 
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: x86-64 and large code model questions/bugs

[Paolo Bonzini]

Andi Kleen wrote:
> On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
>>> He'll get much better code by putting the program into a -fPIC .so,
>>> loading it from a small stub and then unmap the stub.
>>> large model generates really very bad code because all jumps
>>> will be indirect.
>> Is it also true with -fpie?
> 
> Not sure what you mean?

Right, sorry.  I meant "can you also use -fpie and use a linker script
to relocate the text section", if you want to place it high but the code
is not gigantic?

> AFAIK -fpie code is the same quality as -fPIC. Both
> are much much better than large model.

Exactly.

Paolo

Re: x86-64 and large code model questions/bugs

[Andi Kleen]

On Wed, Jan 28, 2009 at 10:21:16AM +0100, Paolo Bonzini wrote:
> Andi Kleen wrote:
> > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
> >>> He'll get much better code by putting the program into a -fPIC .so,
> >>> loading it from a small stub and then unmap the stub.
> >>> large model generates really very bad code because all jumps
> >>> will be indirect.
> >> Is it also true with -fpie?
> > 
> > Not sure what you mean?
> 
> Right, sorry.  I meant "can you also use -fpie and use a linker script
> to relocate the text section", if you want to place it high but the code
> is not gigantic?

That would require -fpie crt*

Probably doable, but needs some more effort than just 
using a classical main() stub.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: Request for testing/help for the LTO branch

[Richard Guenther]

On Tue, Jan 27, 2009 at 11:02 PM, Diego Novillo  wrote:
> On Tue, Jan 27, 2009 at 16:58, H.J. Lu  wrote:
>
>> LTO failed to bootstrap on RHEL5/ia32 and RHEL5/ia64:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38992
>
> Thanks.  This was known to us, though we had not filed a request.
> Essentially, Red Hat distros use a different libelf than the one we
> have been using so far.  We talked a bit about this problem on IRC
> recently and Jakub outlined a possible fix for this.  I will add the
> information to the bug.
>
> I work around the problem on fedora by compiling libelf-0.8.10 and
> building as outlined in the wiki.

It doesn't build on SLES10 either, libelf0-0.8.10-36, it ICEs during
build of libgcc:

...
/gcc/spec/sb-haydn-df-64/gcc/libgcc/../gcc/libgcc2.c:1102: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

libelf shouldn't come into play while building, no?

Program received signal SIGSEGV, Segmentation fault.
output_call_frame_info (for_eh=0)
at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806
806   tree personality = DECL_FUNCTION_PERSONALITY (decl);

#0  output_call_frame_info (for_eh=0)
at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806
#1  0x004ccf37 in dwarf2out_frame_finish ()
at /gcc/spec/sb-haydn-df-64/gcc/gcc/dwarf2out.c:3351
#2  0x00630dd6 in toplev_main (argc=, argv=0x0)
at /gcc/spec/sb-haydn-df-64/gcc/gcc/toplev.c:1023
#3  0x2ae177b25154 in __libc_start_main () from /lib64/libc.so.6
#4  0x00404199 in _start ()

this is on x86_64, the above ICE is with -m32.

Richard.

>
> Diego.
>

-ftime-report might wrap

[Unruh, Erwin]

Hello,

I stumbled over a problem in timevar.c, function timevar_accumulate. When 
USE_CLOCK is set on a 32-bit system, the counter silently wraps around. This 
can result in negative time values, or some time being ignored (because one 
pass uses more than 72 minutes of time).

A check like 
if (stop_time->user < start_time->user)
could detect that problem. (Unless a pass uses 72 minutes in one chunk.)

Erwin

Re: New GCC Runtime Library Exception

[Gerald Pfeifer]

On Tue, 27 Jan 2009, Adam Nemet wrote:
> Gerald Pfeifer  writes:
>> +January 27, 2008
> 2009 ;)

Oops.  Good catch!  I guess that shows this was a bit of a lengthy
process. ;-)

Gerald

Re: Serious code generation/optimisation bug (I think)

[Zoltán Kócsi]

On Tue, 27 Jan 2009 07:08:51 -0500
Robert Dewar  wrote:

> James Dennett wrote:
> 
> > I don't know how much work it would be to disable this optimization
> > in gcc.
> 
> To me, it is always troublesome to talk of "disable this optimization"
> in a context like this. The program in question is not C, and its
> semantics cannot be determined from the C standard. If the appropriate
> gcc switch to "disable" the optimization is set, then the status of
> the program does not change, it is still undefined nonsense. Yes, it
> may happen to "work" for some definition of "work" that is in your
> mind, but is not defined or guaranteed by any coherent language
> definition. It seems worrisome to be operating under such
> circumstances, so surely the best advice in a situation like
> this is to fix the program.

I don't mean to complain, but I happen to work with embedded systems. 
I program them in C, or at least in a language that uses the syntactic
elements of C. While it might not be a C program and is utter nonsense
from a linguistic view, in the embedded world dereferencing a NULL
pointer is often legal and actually unavoidable. Many embedded systems
run on CPUs without MMU and I'd dare to state that there are many more
of these lesser beasts out there than big multicore, superscalar CPUs
with paged MMUs and vector processing units and FPUs. Now on many of
these at location 0 you find a vector table or memory mapped registers
or simple memory or even the dreaded zero-page where you can do things
that you can't do anywhere else. On every one of those chips it is
legal to dereference a NULL pointer as long as you have the notion of
a pointer being an address of something. I've been programming in C for
almost 30 years and I neglectfully not followed the language's semantic
development, maybe that's why I am confused to think that C is a
low-level, system programming language and not a highly abstract
language where a "pointer" is actually some sort of a complex
reference to an object that may or may not actually occupy memory.
Assuming, of course, that the notion of "memory" is still a valid one,
in the old sense of collection of addressable data units residing in a
so-called address space. I think the existence of keywords referring to
aliasing is an indication to that, but I am not sure any more.

In that caveman mental domain of mine I would assume that if I
dereference a NULL pointer and on the given environment it is a no-no,
then something nasty is going to happen; an exception is raised on a
micro or I get a sig 11 message on my terminal or the whole gizmo just
resets out of the blue. On the other hand, if the given architecture
treats address 0 as address 0, then it should just fetch whatever value
is at 0 and merrily chug along. In fact, I would assume that since on
every CPU I've ever used the address space included 0, one could do
this:

// 32-bit ints
struct s_addr_space {
  int preg[ 0x100 ];// 256 memory mapped peripherial register @ 0
  int gap1[ 0x300 ];// 3K Unused space
  int ether[ 0x400 ];   // 4K Ethernet buffer
  char video[ 0x4000 ]; // 16K video buffer
  int gap2[ 0x800 ];// 8K unused
  int ram[ 0x1000 ];// 16K RAM
  int rom[0x1000 ]; // 16K ROM
...
} * const my_micro = (struct s_addr_space *) 0;

...
   if ( my_micro->video[ 3 ] == 'A' ) { ...

Then I would not assume that the compiler simply throws away each and
every statement that refers to any element of the address space just
because it cleary knows that 'my_micro' is a NULL pointer, therefore 
it can, in its superior wisdom, declare that the code dereferencing
it should not and thus will not be executed whatsoever.

It is possible that the above is complete nonsense and should be
punished by public execution of the programmer, but there are *tons* 
of stuff like that out there on embedded systems, working quite nicely.

I openly admit that the test case was sloppy (and admitted it in my OP).
I do accept that due to the elevation of the C language from the low
level system programming language it used to be to the linguisticly
pure high-level object oriented metalanguage that C-99 apparently is,
dereferencing a NULL pointer became meaningless nonsense these days.

However, I'd like to point out one thing: the compiler is there to help
the programmer. Derefencing a NULL pointer might be a bad thing on one
system and perfectly normal on others. The standard declares that the
behaviour is undefined, i.e. it is up to the compiler writer. Now on a
system where NULL dereference is allowed, silently(!) removing an
explicite test for NULL pointer (indicating that the programmer *knew*
that the pointer can indeed be NULL) is the worst possible solution. It
does not save the program from crashing if the pointer was NULL and the
system does not tolerate it. On the other hand, on a NULL-tolerant
system it makes code that, if the compiler hadn't overruled the
programmer, would have worked just fine but due to the compiler's
d

Re: Serious code generation/optimisation bug (I think)

[Andrew Haley]

Zoltán Kócsi wrote:
> On Tue, 27 Jan 2009 07:08:51 -0500
> Robert Dewar  wrote:
>
>> James Dennett wrote:
>>
>>> I don't know how much work it would be to disable this optimization
>>> in gcc.
>> To me, it is always troublesome to talk of "disable this optimization"
>> in a context like this. The program in question is not C, and its
>> semantics cannot be determined from the C standard. If the appropriate
>> gcc switch to "disable" the optimization is set, then the status of
>> the program does not change, it is still undefined nonsense. Yes, it
>> may happen to "work" for some definition of "work" that is in your
>> mind, but is not defined or guaranteed by any coherent language
>> definition. It seems worrisome to be operating under such
>> circumstances, so surely the best advice in a situation like
>> this is to fix the program.
>
> I don't mean to complain, but I happen to work with embedded
> systems.  I program them in C, or at least in a language that uses
> the syntactic elements of C. While it might not be a C program and
> is utter nonsense from a linguistic view, in the embedded world
> dereferencing a NULL pointer is often legal and actually
> unavoidable.

No, that's not true: accessing memory at address zero may be necessary,
but that is not the same as dereferencing a NULL pointer.  This may
sound like a minor and pedantic point, but I don't think it is: it goes
to the very core of this misunderstanding.

> Many embedded systems run on CPUs without MMU and I'd dare to state
> that there are many more of these lesser beasts out there than big
> multicore, superscalar CPUs with paged MMUs and vector processing
> units and FPUs. Now on many of these at location 0 you find a vector
> table or memory mapped registers or simple memory or even the
> dreaded zero-page where you can do things that you can't do anywhere
> else. On every one of those chips it is legal to dereference a NULL
> pointer as long as you have the notion of a pointer being an address
> of something.

If it's an embedded system, and your program is tied to particular
hardware with system data at address zero, you might as well access
that data with an asm; that's not going to reduce portability any.

> I openly admit that the test case was sloppy (and admitted it in my
> OP).  I do accept that due to the elevation of the C language from
> the low level system programming language it used to be to the
> linguisticly pure high-level object oriented metalanguage that C-99
> apparently is, dereferencing a NULL pointer became meaningless
> nonsense these days.

No, this is since C90; nothing has changed in this area.  NULL
doesn't mean "address 0", it means "nothing".  The C statement

  if (ptr)

doesn't mean "if ptr does not point to address zero", it means "if ptr
points to something".

> However, I'd like to point out one thing: the compiler is there to
> help the programmer. Derefencing a NULL pointer might be a bad thing
> on one system and perfectly normal on others.

> From a C language standard purist point of view such code might be
> nonsense, but chances are that you own and use some gadget every day
> that was programmed by such low-life engineers like me who live in
> those by-gone days where a pointer held a memory address and work
> with chips where at address 0 there are some useful things.

I think you perhaps need to be a little less patronizing.  Many of us,
myself included, have done a great deal of embedded programming and we
know what the issues are.  You have written an incorrect program, and
you now know what was incorrect about it.

> So, pretty please, when the compiler detects that a language
> resembling to, but not really C is used and removes assumedly
> (albeit unprovenly) superfluos chunks of code to purify the
> misguided programmer's intent, could it please at least send a
> warning?

In practice that's a lot harder than you might think.  If we were to
issue a warning for every transformation we made based on the
semantics of the C language I'm sure people would complain.  "You
can't dereference a NULL pointer" is a fundamental part of the
language.

Andrew.

Re: Serious code generation/optimisation bug (I think)

[Robert Dewar]

Zoltán Kócsi wrote:

I don't mean to complain, but I happen to work with embedded systems. 
I program them in C, or at least in a language that uses the syntactic

elements of C.


Yes, and that is an important distinction. If you program in C, you
should program in C (and know the language).


While it might not be a C program and is utter nonsense
from a linguistic view, in the embedded world dereferencing a NULL
pointer is often legal and actually unavoidable. 


The trouble is that this is not defined in C, so if you need to
do something reliably that is not supported by the language you
have chosen to program in, you should use a machine language
insertion, that's the only reliable way to get what you want.

Once you start trying to go outside what the language you are
using defines, you are asking for big trouble.



MOn every one of those chips it is
legal to dereference a NULL pointer as long as you have the notion of
a pointer being an address of something. I've been programming in C for
almost 30 years and I neglectfully not followed the language's semantic
development, maybe that's why I am confused to think that C is a
low-level, system programming language and not a highly abstract
language where a "pointer" is actually some sort of a complex
reference to an object that may or may not actually occupy memory.


People who program in C under the illusion that it is a simply defined
low level language where they don't have to worry about the formal
abstraction, are working indeed under an illusion.


Assuming, of course, that the notion of "memory" is still a valid one,
in the old sense of collection of addressable data units residing in a
so-called address space. I think the existence of keywords referring to
aliasing is an indication to that, but I am not sure any more.

In that caveman mental domain of mine I would assume that if I
dereference a NULL pointer and on the given environment it is a no-no,
then something nasty is going to happen; an exception is raised on a
micro or I get a sig 11 message on my terminal or the whole gizmo just
resets out of the blue. On the other hand, if the given architecture
treats address 0 as address 0, then it should just fetch whatever value
is at 0 and merrily chug along. In fact, I would assume that since on
every CPU I've ever used the address space included 0, one could do
this:


Your attitude is reasonable in the abstract, but unfortunately the
semantics of C does not correspond to this abstraction.


So, pretty please, when the compiler detects that a language resembling
to, but not really C is used and removes assumedly (albeit unprovenly)
superfluos chunks of code to purify the misguided programmer's intent,
could it please at least send a warning?


That's a reasonable request, although for technical questions it is
often harder than you might imagine to give such warnings.


Just to indicate to those
idiots who are at least aware of their dumbness and thus use -W -Wall
-Wextra -Werror in their CFLAGS that it is now time to purchase the
latest C standard and brush up with the recent changes with regards to
the interpretation semantics of such things as addresses, arrays,
pointers and so on.


If you do, you will be shocked :-)

Re: Request for testing/help for the LTO branch

[Rainer Orth]

Diego Novillo  writes:

> Essentially, the biggest areas where we need help are:
> 
> - Testing on other targets.  We have only tested on x86 (32 and 64
> bit) targets.  I'm pretty sure other targets are either non-functional
> or show major breakage.  We'd appreciate any daily tester that could
> include the branch and report bugs to bugzilla (feel free to assign to
> me).

Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)?

Rainer

-- 
-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: gcc-4.3.3 bootstrap fails on old Sun Sparc

[Rainer Orth]

Andreas Schwab  writes:

> Dennis Clarke  writes:
> 
> > One of the things I have had no joy with is figuring out how to
> > include the ada component but that is a battle for another day.
> 
> To build ada you need a good ada compiler to start with.  If you don't
> have one natively you need to build a cross compiler on a system that
> has one and then build the native ada compiler with this cross
> compiler.  Then you can rebootstrap with ada enabled.

Probably lots of hassle.  If needed, I can provide bootstrap GNAT for both
Solaris/SPARC and x86, since I (sort of) regularly test on both platforms
with Ada included.

Rainer

-- 
-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Request for testing/help for the LTO branch

[Rainer Orth]

Rafael Espindola writes:

> > Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)?
> 
> We need ELF for storing the IL files. In theory that is only a
> container format and you could crate a plugin for the IRIX linker to
> read it.

I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets
(just not Linux, so using the system linker, not GNU ld).  If I understand
you correctly, they might just work (modulo bugs)?

The only other target of interest to me is Tru64 UNIX, which uses ECOFF,
not ELF.  I don't know if that format is extensible enough to store the IL,
but investigating that is low priority for me.

Thanks.
Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Request for testing/help for the LTO branch

[Rafael Espindola]

> I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets
> (just not Linux, so using the system linker, not GNU ld).  If I understand
> you correctly, they might just work (modulo bugs)?

That should work. You still might need to extend the linker  to
support IL in static libraries. We can work with normal .o with the
modified collect2 in the branch, but for archives we need linker
support.

> The only other target of interest to me is Tru64 UNIX, which uses ECOFF,
> not ELF.  I don't know if that format is extensible enough to store the IL,
> but investigating that is low priority for me.

I  would suggest trying to use elf for the IL. For example, while
using plugins gold doesn't care what the *input* file format is.

> Thanks.
>Rainer
>
> -
> Rainer Orth, Faculty of Technology, Bielefeld University
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: Request for testing/help for the LTO branch

[Rafael Espindola]

> Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)?

We need ELF for storing the IL files. In theory that is only a
container format and you could crate a plugin for the IRIX linker to
read it.

>Rainer

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: Request for testing/help for the LTO branch

[Diego Novillo]

On Wed, Jan 28, 2009 at 00:06, Chris Lattner  wrote:

> Thanks for the summary, it's great to see the progress of the project.  Do
> you have any compile time numbers for LTO so far?  If you pick a mid-sided
> program from spec or even a bootstrap, how much slower is LTO than compiling
> at -O3?

The compiler still cannot bootstrap itself with LTO enabled (at least
not as of 2-3 months ago) and while we haven't been doing any serious
timings.  The SPEC2000 builds I've done with LTO enabled show
slowdowns between 2x and 3x (the compiler generates code twice, once
during cc1/cc1plus and the second time during lto1).

I have no idea how this fares in SPEC2k6.  In terms of scores, they
are annoyingly flat.  Still haven't analyzed why.


Diego.

Re: Request for testing/help for the LTO branch

[Diego Novillo]

On Wed, Jan 28, 2009 at 05:36, Richard Guenther
 wrote:

> /gcc/spec/sb-haydn-df-64/gcc/libgcc/../gcc/libgcc2.c:1102: internal
> compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
>
> libelf shouldn't come into play while building, no?

It does when building the plugin and lto1.  But the ICE here is due to
cleanups we've made in the branch.  These affect both LTO and non-LTO
builds.

> Program received signal SIGSEGV, Segmentation fault.
> output_call_frame_info (for_eh=0)
>at /gcc/spec/sb-haydn-df-64/gcc/gcc/expr.h:806
> 806   tree personality = DECL_FUNCTION_PERSONALITY (decl);

Ah, yes, thanks for confirming.  I have seen this one but still have
not come around to fixing it.  This is due to the changes done to
personality functions
(http://gcc.gnu.org/ml/gcc/2009-01/msg00074.html).

I need to follow-up to Cary's suggestion for a fix.  Could you create
a bug for this one so I stop forgetting about it?


Thanks.  Diego.

Re: Request for testing/help for the LTO branch

[Diego Novillo]

On Wed, Jan 28, 2009 at 06:56, Rainer Orth  
wrote:

> Any chance that it works on non-GNU/Linux ELF targets (like Solaris, IRIX)?

Yes, it should work on any ELF target.


Diego.

c-4_5-branch merge plan

[Joseph S. Myers]

Once 4.4 has branched I plan to merge the changes from c-4_5-branch to 
trunk.  I plan to merge in three logical patches, each one with a logical 
change from the branch and all followups to that change combined into a 
single trunk commit, rather than merging the whole branch at once.

* Constant expressions, VLA size evaluation and delaying folding.  Main 
patch with further information: 
.  Fixes bugs 
456, 5675, 19976, 29116, 31871, 35198 and all other known 
target-independent constant expressions or VLA size evaluation C90 and C99 
conformance issues as illustrated by the many testcases added.

* C99-conforming excess precision.  Main patch: 
.  Fixes bug 323 
for C (other languages would need their own front-end work to implement 
suitable predictable semantics under the same command-line option in order 
to complete fixing the bug).

* stdint.h.  Main patch: 
.  Fixes bug 448 
for glibc/uClibc, newlib and Solaris.  Can be extended to fix for other 
targets by defining appropriate macros in the relevant tm.h headers and 
setting use_gcc_stdint appropriately in config.gcc according to whether 
the target has its own stdint.h header.  Once this is in I'll post a list 
of target OSes needing these definitions (and if necessary, in due course 
propose deprecations of targets for which no-one has added the 
definitions, so we can move to the state where target stdint.h can be 
presumed to be available and the Fortran compiler will always have the 
information needed for the bindings to these types).

The excess precision patch depends on the constant expressions patch.  
There are no dependencies between the stdint.h patch and the others.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Request for testing/help for the LTO branch

[Rainer Orth]

Rafael Espindola writes:

> > I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets
> > (just not Linux, so using the system linker, not GNU ld).  If I understand
> > you correctly, they might just work (modulo bugs)?
> 
> That should work. You still might need to extend the linker  to
> support IL in static libraries. We can work with normal .o with the
> modified collect2 in the branch, but for archives we need linker
> support.

Ok, I see.  Maybe we can extend Sun ld to handle that, given that the
sources are now open via OpenSolaris.

> > The only other target of interest to me is Tru64 UNIX, which uses ECOFF,
> > not ELF.  I don't know if that format is extensible enough to store the IL,
> > but investigating that is low priority for me.
> 
> I  would suggest trying to use elf for the IL. For example, while
> using plugins gold doesn't care what the *input* file format is.

Unfortunately, gold doesn't even build on non-Linux targets: see PR
gold/7024.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Request for testing/help for the LTO branch

[Diego Novillo]

On Wed, Jan 28, 2009 at 08:11, Rainer Orth  
wrote:

> Unfortunately, gold doesn't even build on non-Linux targets: see PR
> gold/7024.

Note that you don't really need gold to use LTO.  It works just fine
with GNU ld.
What you get with gold and the linker plugin is mostly the ability to
open up .a archives.


Diego.

Re: Request for testing/help for the LTO branch

[Rainer Orth]

Diego Novillo writes:

> On Wed, Jan 28, 2009 at 08:11, Rainer Orth  
> wrote:
> 
> > Unfortunately, gold doesn't even build on non-Linux targets: see PR
> > gold/7024.
> 
> Note that you don't really need gold to use LTO.  It works just fine
> with GNU ld.

But at least on Solaris, using GNU ld is sort of a problem: there are lots
of GCC testsuite regressions right now, and GNU ld doesn't support several
of Sun ld's advanced features, which is why I very much prefer to use the
native linker if at all possible.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Request for testing/help for the LTO branch

[Joseph S. Myers]

On Wed, 28 Jan 2009, Rainer Orth wrote:

> Rafael Espindola writes:
> 
> > > I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets
> > > (just not Linux, so using the system linker, not GNU ld).  If I understand
> > > you correctly, they might just work (modulo bugs)?
> > 
> > That should work. You still might need to extend the linker  to
> > support IL in static libraries. We can work with normal .o with the
> > modified collect2 in the branch, but for archives we need linker
> > support.
> 
> Ok, I see.  Maybe we can extend Sun ld to handle that, given that the
> sources are now open via OpenSolaris.
> 
> > > The only other target of interest to me is Tru64 UNIX, which uses ECOFF,
> > > not ELF.  I don't know if that format is extensible enough to store the 
> > > IL,
> > > but investigating that is low priority for me.
> > 
> > I  would suggest trying to use elf for the IL. For example, while
> > using plugins gold doesn't care what the *input* file format is.
> 
> Unfortunately, gold doesn't even build on non-Linux targets: see PR
> gold/7024.

That actually appears to be a list of issues with non-Linux hosts, not 
non-Linux targets.

I would certainly hope both LTO and gold should work on a wide range of 
non-Linux hosts (if anyone cares to contribute patches for such support), 
including non-ELF hosts, even though restricted to ELF targets at least in 
the case of gold.  libelf definitely works on MinGW and Solaris hosts.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Request for testing/help for the LTO branch

[Diego Novillo]

On Wed, Jan 28, 2009 at 08:18, Rainer Orth  
wrote:

> But at least on Solaris, using GNU ld is sort of a problem: there are lots
> of GCC testsuite regressions right now, and GNU ld doesn't support several
> of Sun ld's advanced features, which is why I very much prefer to use the
> native linker if at all possible.

Sorry, when I said 'GNU ld', I really meant 'any ld'.  It should work
with *any* linker.  The basic IL detection mechanism and lto1
launching is done in collect2.  We don't rely on any linker feature to
do the work.


Diego.

Re: Request for testing/help for the LTO branch

[Rainer Orth]

Diego Novillo writes:

> On Wed, Jan 28, 2009 at 08:18, Rainer Orth  
> wrote:
> 
> > But at least on Solaris, using GNU ld is sort of a problem: there are lots
> > of GCC testsuite regressions right now, and GNU ld doesn't support several
> > of Sun ld's advanced features, which is why I very much prefer to use the
> > native linker if at all possible.
> 
> Sorry, when I said 'GNU ld', I really meant 'any ld'.  It should work
> with *any* linker.  The basic IL detection mechanism and lto1
> launching is done in collect2.  We don't rely on any linker feature to
> do the work.

Great to hear: I'll just give it a try on Solaris and IRIX and report what
I find.

Thanks.
Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Request for testing/help for the LTO branch

[Diego Novillo]

On Wed, Jan 28, 2009 at 08:18, Joseph S. Myers  wrote:

> I would certainly hope both LTO and gold should work on a wide range of
> non-Linux hosts (if anyone cares to contribute patches for such support),
> including non-ELF hosts, even though restricted to ELF targets at least in
> the case of gold.  libelf definitely works on MinGW and Solaris hosts.

I will update the wiki with clarification on this issue.  To reiterate:

- LTO functionality does not depend on the linker.  We only take
advantage of gold and its plugin to pull objects out of .a files.

- LTO does depend on ELF.  It would be nice to support non-ELF targets
but it's not in our immediate plans.


Diego.

Re: Request for testing/help for the LTO branch

[Rainer Orth]

Joseph S. Myers writes:

> > Unfortunately, gold doesn't even build on non-Linux targets: see PR
> > gold/7024.
> 
> That actually appears to be a list of issues with non-Linux hosts, not 
> non-Linux targets.

Right, I had ignored non-native builds since I rarely do them.

> I would certainly hope both LTO and gold should work on a wide range of 
> non-Linux hosts (if anyone cares to contribute patches for such support), 
> including non-ELF hosts, even though restricted to ELF targets at least in 
> the case of gold.  libelf definitely works on MinGW and Solaris hosts.

I'll give it a try, although at least on Solaris and IRIX there is a
conflict with the native libelf.  I haven't yet checked if the interfaces
are the same, but I suppose not.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

New GCC Runtime Library Exception: not fit for purpose

[Joern Rennecke]

The definition of 'independent module' is such that it does not include files
that make no use of any runtime interfaces at all.  E.g. a newlib file
is an independent module if it uses a multiply and that multiply is
implemented as a libgcc function all by gcc, but if the multiply is
implemented by gcc with straightline assembly code, and there is no other
use of the Runtime library in this file, it will not qualify.
There are likely a large number of files in newlib that will not have a
Runtime library dependence at all on any target.

Moreover, even if the language would be fixed to allow files that have no
dependence on the runtime library, that would still not allow the inclusion
of files from newlib/libc/sys or newlib/libc/machine which are written
in assembly code:
The object files generated from these assembly sources are not included
in the definition of target code (it is not the output of a compiler).
Also, the assembly of these files is not a compilation process, since  
the input

is not a high level language.

Likewise, lots of third-party libraries will fall foul of these definitions
because some files do not use a Runtime library interface, and/or it contains
parts not coded in a high level language.

Note that there is also code which is not written in a high level language
which uses gcc runtime library interfaces.  For example, look at
libgloss/m68k/crt0.S , which uses __do_global_dtors .
That the license of libgloss is GPL-compatible does not help here,
since we want to allow people to link programs containing non-GPL-compatible
code simultanously against libgloss and libgcc.

Re: Serious code generation/optimisation bug (I think)

[Zoltán Kócsi]

> No, this is since C90; nothing has changed in this area.  NULL
> doesn't mean "address 0", it means "nothing".  The C statement
> 
>   if (ptr)
> 
> doesn't mean "if ptr does not point to address zero", it means "if ptr
> points to something".

A question then:

How can I make a pointer to point to the integer located at address
0x0? It is a perfectly valid object, it exists, therefore I should be
able to get its address? In fact, if I have a CPU that starts its data
RAM at 0, then the first data object *will* reside at address 0 and
thus taking its address will result in a pointer that has all its bits
clear. Obviously that pointer then should not be equal to NULL, since
it was obtained by taking the address of a valid object, that is, the
pointer indeed points to something. Therefore,

int *a = &first_object;
int *b = (int *) 0;

must result in different values in a and b. Will it?

> I think you perhaps need to be a little less patronizing.

I did not want to be patronising. I wanted to be sarcastic, yes, but
not patronising at all.

> Many of us,
> myself included, have done a great deal of embedded programming and we
> know what the issues are.  You have written an incorrect program, and
> you now know what was incorrect about it.

Yes, I know. However, my problem is not that the program was not
correct. It wasn't and I have admitted it from the beginning. My problem
was that the compiler removed a test on an assumption. It could not
*prove* that the pointer was not NULL. It merely *assumed* it. It can
argue that what I did was wrong, but then it should have told me so. It
did not say anything. It simply decided that since it saw me do
something with a datum, the datum can not possibly be a certain value,
because I should not do that with a datum if it is that certain value.
It was wrong.

If I write

int x[ 10 ];
void foo( int i )
{
   bar( x[ i ] );
   if ( i >= 10 || i < 0 ) { ...

According to the C semantics you shouldn't under or overindex an
array. Thus, you could safely remove the if(). Since I indexed a
10-element array with it, 'i' could not possibly be less than 0 
or more than 9. 

Actually, the pointer (x+13) does not point to any valid object.
Thus, (x+13) == NULL should evaluate true, shouldn't it?

The same elimination should be true to this:

  a = b / c; 
  if ( ! c )

for you can't divide by 0, thus c can not possibly be 0. Does gcc
silently remove the if in the above case?

> > So, pretty please, when the compiler detects that a language
> > resembling to, but not really C is used and removes assumedly
> > (albeit unprovenly) superfluos chunks of code to purify the
> > misguided programmer's intent, could it please at least send a
> > warning?
> 
> In practice that's a lot harder than you might think.  If we were to
> issue a warning for every transformation we made based on the
> semantics of the C language I'm sure people would complain.  "You
> can't dereference a NULL pointer" is a fundamental part of the
> language.

I think I see where your semantics and mine are different:

You say: "You can't dereference a NULL pointer"

I say: "You shouldn't dereference a NULL pointer"

I shouldn't but I most certainly can. I can generate a NULL pointer
where the compiler can not prove (at compile time) that it is NULL. 
If I dereference it, then whatever happens is my problem. I should not
do that but I can and if I do, I take the consequences. The compiler,
in my opinion, must not assume that just because something should not
be done it can not possibly be done. Actually, it should not assume
things at all. Rather, it should prove things before making a
transformation. If it makes a transformation based on nothing more 
than its assumptions, then at least it should give me a warning.

When you eliminate this condition:

unsigned int x;

  if ( x >= 0 ) {

then you are not assuming anything. You know, by definition, that the
condition is true, it's a proven fact. Yet the compiler issues a
warning. 

Or when facing this snipet:

int x, y;

   for ( x = 0 ; x < 10 ; x++ )
 if ( ! x )
y = 3;
 else
y = y + x;

the compiler complains that 'y' might be used uninitialised (well, gcc
might be able to work out *that* one but a slightly more complex would
be beyond its reach). Since it could not *prove* that y was on the LHS
before being used on the RHS it issues a warning.

However, when you eliminate this:

z = *p;

if ( ! p ) {

you *assume* that p was not NULL, because according to the standard
it should not have been. You have absolutely no way to prove it that
it really wasn't. Yet you eliminate the if() without warning.

See my problem?

Zoltan

Re: x86-64 and large code model questions/bugs

[H.J. Lu]

On Wed, Jan 28, 2009 at 1:40 AM, Andi Kleen  wrote:
> On Wed, Jan 28, 2009 at 10:21:16AM +0100, Paolo Bonzini wrote:
>> Andi Kleen wrote:
>> > On Wed, Jan 28, 2009 at 09:39:39AM +0100, Paolo Bonzini wrote:
>> >>> He'll get much better code by putting the program into a -fPIC .so,
>> >>> loading it from a small stub and then unmap the stub.
>> >>> large model generates really very bad code because all jumps
>> >>> will be indirect.
>> >> Is it also true with -fpie?
>> >
>> > Not sure what you mean?
>>
>> Right, sorry.  I meant "can you also use -fpie and use a linker script
>> to relocate the text section", if you want to place it high but the code
>> is not gigantic?
>
> That would require -fpie crt*
>
> Probably doable, but needs some more effort than just
> using a classical main() stub.
>

It works fine with the latest binutils from CVS:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38988#c4


-- 
H.J.

Re: Serious code generation/optimisation bug (I think)

[Andreas Schwab]

Zoltán Kócsi  writes:

> How can I make a pointer to point to the integer located at address
> 0x0? It is a perfectly valid object, it exists, therefore I should be
> able to get its address? In fact, if I have a CPU that starts its data
> RAM at 0, then the first data object *will* reside at address 0 and
> thus taking its address will result in a pointer that has all its bits
> clear.

Then you should define the null pointer to be not all bits zero on this
platform.

Andreas.

-- 
Andreas Schwab, SuSE Labs, sch...@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: cross-compilation, deprecated option and libgcc

[Vincent R.]

On Tue, 27 Jan 2009 09:16:10 +1100, Ben Elliston  wrote:
> On Mon, 2009-01-26 at 14:19 +0100, Vincent R. wrote:
> 
>> 1) When I compile bootstrap gcc, I am using make all-gcc and make
>> install-gcc and it seems it doesn't build libgcc anymore.
> 
> I think that's correct; make all-gcc just builds gcc these days.  To
> build libgcc, you need to run make all-target-libgcc.  libgcc is no
> longer built as part of gcc, but like any other of the target libraries.
> 
> It's best to do a make all and make install to avoid these hassles.  If
> you want to keep the workload down, use --enable-languages to prune the
> set of languages you support in your "bootstrap" compiler.  (Is there a
> reason why you can't just build the cross using your system compiler?)
> 
>> So my first question is : For a bootstrap gcc do I need to build libgcc
>> and
>> in this case should I use make all and make install instead ?
> 
> Yes.
> 
> Cheers, Ben

Ok so one last effort and I will stop to annoy everyone ;-)
Here is the situation, I have built binutils, copied headers into my my
sysroot folder (/opt-mingw32ce-4.4.0),
and generate a bootstrap gcc targeting arm-mingw32ce (a wince-pe target
with mingw32).
So far so good, now the problem arises when trying to compile mingw :

 arm-mingw32ce-gcc -Wl,--base-file=mingwthrd.base -B./ -mdll 
-Wl,--image-base,0x6FBC mthr.o mthr_init.o -Lmingwex -o
mingwthrd_dummy.exe
/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/libgcc.a(__main.o): In
function `__do_global_ctors':
/home/vincent/projects/cegcc-4.4.0/src/gcc/libgcc/../gcc/libgcc2.c:2162:
undefined reference to `atexit'
/home/vincent/projects/cegcc-4.4.0/src/gcc/libgcc/../gcc/libgcc2.c:2162:
relocation truncated to fit: ARM_26 against undefined symbol `atexit'
/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/crtend.o:cygming-crtend.c:(.text+0x14):
undefined reference to `atexit'
/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/crtend.o:cygming-crtend.c:(.text+0x14):
relocation truncated to fit: ARM_26 against undefined symbol `atexit'
./dllcrt3.o: In function `DllMainCRTStartup':
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:128: undefined
reference to `__atexit_first'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:128: relocation
truncated to fit: ARM_26 against undefined symbol `__atexit_first'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:140: undefined
reference to `__dll_exit'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:140: relocation
truncated to fit: ARM_26 against undefined symbol `__dll_exit'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:68: undefined
reference to `__atexit_init'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:68: relocation
truncated to fit: ARM_26 against undefined symbol `__atexit_init'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:86: undefined
reference to `_pei386_runtime_relocator'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:86: relocation
truncated to fit: ARM_26 against undefined symbol
`_pei386_runtime_relocator'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:140: undefined
reference to `__dll_exit'
/home/vincent/projects/cegcc-4.4.0/src/mingw/dllcrt1.c:140: relocation
truncated to fit: ARM_26 against undefined symbol `__dll_exit'

As you can see some symbols are missing and when looking for their
definitions I found out that they were compiled just before and put in a
library called libmingw32.a :

arm-mingw32ce-ar rc libmingw32.a CRTglob.o CRTfmode.o CRTinit.o dllmain.o
gccmain.o crtst.o mthr_stub.o pseudo-reloc.o pseudo-reloc-list.o
cpu_features.o winmain_ce.o abort.o atexit.o assert.o
arm-mingw32ce-ranlib libmingw32.a

So I have added -lmingw32 to the mingw Makefile.in and I was able to
compile and install it : 
mingw/Makefile.in
DLL_CC_STUFF  = -B./ -mdll $(MNO_CYGWIN) -Wl,--image-base,0x6FBC \
\
$(DLL_OFILES) \
-Lmingwex -lmingw32

The final step in my toolchain is to generate a full compiler, so now I
solved all this I thought it would work but actually
I get the same kind of error during the compilation of libssp : 

checking sys/param.h usability... libtool: link:
/home/vincent/projects/cegcc-4.4.0/src/build-mingw32ce/gcc/./gcc/xgcc
-B/home/vincent/projects/cegcc-4.4.0/src/build-mingw32ce/gcc/./gcc/
-L/home/vincent/projects/cegcc-4.4.0/src/build-mingw32ce/gcc/arm-mingw32ce/winsup/mingw
-L/home/vincent/projects/cegcc-4.4.0/src/build-mingw32ce/gcc/arm-mingw32ce/winsup/w32api/lib
-isystem /home/vincent/projects/cegcc-4.4.0/src/gcc/winsup/mingw/include
-isystem /home/vincent/projects/cegcc-4.4.0/src/gcc/winsup/w32api/include
-B/opt/mingw32ce-4.4.0/arm-mingw32ce/bin/
-B/opt/mingw32ce-4.4.0/arm-mingw32ce/lib/ -isystem
/opt/mingw32ce-4.4.0/arm-mingw32ce/include -isystem
/opt/mingw32ce-4.4.0/arm-mingw32ce/sys-include -shared  .libs/ssp.o
.libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o
.libs/memset-chk.o .libs/snprintf-chk.o 

New GCC Runtime Library Exception: amendment proposal

[Joern Rennecke]

A file is an "Independent Module" if it is not based on the Runtime
Library, except that it may either require the Runtime Library for  
execution after a Compilation Process, or make use of an interface  
provided by the

Runtime Library.

Definitions of "GCC" and "GPL-compatible sotware as in the original.

"Target Code" refers to output from any compiler for a real or virtual  
target processor architecture, in executable form or suitable for  
input to an assembler, loader, linker and/or execution phase.  
Notwithstanding that, Target Code does not include data in any format  
that is used as a compiler intermediate representation, or used for  
producing a compiler intermediate representation.

Where code written in assembly language is Source Code as defined in GPLv3,
it shall also be considered "Target Code".

The "Compilation Process" transforms code entirely represented in a  
high-level, non-intermediate language into Target Code. Thus, for  
example, use of source code generators and preprocessors need not be  
considered part of the Compilation Process, since the Compilation  
Process can be understood as starting with the output of the  
generators or preprocessors.

Where the Source Code as defined in GPLv3 is not written in a high-level
language, yet not in assembly code, the "Compilation Process" transforms the
code entirely represented in Source Code into Target Code.

Defintion of "Eligible" Compilation process as in original.

1. Grant of Additional Permission.

You have permission to propagate a work of Target Code formed by  
combining the Runtime Library with Independent Modules, even if such  
propagation would otherwise violate the terms of GPLv3, provided that  
all Target Code was eithwe generated by Eligible Compilation  
Processes. You may then convey such a combination under terms of your  
choice, consistent with the licensing of the Independent Modules.

PS: New GCC Runtime Library Exception: amendment proposal

[Joern Rennecke]

Sorry, something went wrong while I edited the message and it was sent
prematurely.

Quoting Joern Rennecke :


A file is an "Independent Module" if it is not based on the Runtime
Library, except that it may either require the Runtime Library for
execution after a Compilation Process, or make use of an interface
provided by the
Runtime Library.

Definitions of "GCC" and "GPL-compatible sotware as in the original.

"Target Code" refers to output from any compiler for a real or virtual
target processor architecture, in executable form or suitable for input
to an assembler, loader, linker and/or execution phase. Notwithstanding
that, Target Code does not include data in any format that is used as a
compiler intermediate representation, or used for producing a compiler
intermediate representation.
Where code written in assembly language is Source Code as defined in GPLv3,
it shall also be considered "Target Code".

The "Compilation Process" transforms code entirely represented in a
high-level, non-intermediate language into Target Code. Thus, for
example, use of source code generators and preprocessors need not be
considered part of the Compilation Process, since the Compilation
Process can be understood as starting with the output of the generators
or preprocessors.
Where the Source Code as defined in GPLv3 is not written in a high-level
language, yet not in assembly code, the "Compilation Process" transforms the
code entirely represented in Source Code into Target Code.

Defintion of "Eligible" Compilation process as in original.

1. Grant of Additional Permission.


You have permission to propagate a work of Target Code formed by
combining the Runtime Library with Independent Modules, even if such
propagation would otherwise violate the terms of GPLv3, provided that
all Target Code was either generated by Eligible Compilation Processes,
or is Source Code as defined in GPLv3.
You may then convey such a combination under terms of your choice,
consistent with the licensing of the Independent Modules.

PPS: New GCC Runtime Library Exception: amendment proposal

[Joern Rennecke]

Hmm, I didn't specifically think of the case where the Source code is
not a high level language, but a code generator is used to generate
a high-level language which is to be compiled with gcc.
E.g. someone might have some assembly Source Code which they translate
to C to migrate to new hardware, and for some reason the assembly-to-C
translator is not GPL compatible.
Presumably we want to allow the use of GCC as well.

However, the wording I gave should cover this fine as well - the assembly /
object code generated from the generated C code is in this code Target
Code with can be generated by an Eligible Compilation Process from the
generated C code.

Still, this is something to keep in mind when trying to further amend and/or
simplify the proposal.

Re: gcc-4.3.3 bootstrap fails on old Sun Sparc

[Dennis Clarke]

> Andreas Schwab  writes:
>
>> Dennis Clarke  writes:
>>
>> > One of the things I have had no joy with is figuring out how to
>> > include the ada component but that is a battle for another day.
>>
>> To build ada you need a good ada compiler to start with.  If you don't
>> have one natively you need to build a cross compiler on a system that
>> has one and then build the native ada compiler with this cross
>> compiler.  Then you can rebootstrap with ada enabled.
>
> Probably lots of hassle.  If needed, I can provide bootstrap GNAT for both
> Solaris/SPARC and x86, since I (sort of) regularly test on both platforms
> with Ada included.
>
>   Rainer

Dear Sir :

Would there be any way that I could invite you into the community
build farm at Blastwave.org for this purpose ? I think it would be
great if we could get a GCC package built ( with ada ) that passes a
set of QC/QA steps and then release it to the Solaris world. Clearly
I'll need a bit of help with the ada portion.

All I would need is a public key from you and then you could ssh in
through the gateway and into the server farm on any architecture or OS
level that you want. This is something that Blastwave does for
community open source people for years and it works rather well.

Dennis

Re: Serious code generation/optimisation bug (I think)

[Andrew Haley]

Zoltán Kócsi wrote:
>> No, this is since C90; nothing has changed in this area.  NULL
>> doesn't mean "address 0", it means "nothing".  The C statement
>>
>>   if (ptr)
>>
>> doesn't mean "if ptr does not point to address zero", it means "if ptr
>> points to something".
> 
> A question then:
> 
> How can I make a pointer to point to the integer located at address
> 0x0?

Didn't we address this before?  You can't.

> It is a perfectly valid object, it exists, therefore I should be
> able to get its address? In fact, if I have a CPU that starts its data
> RAM at 0, then the first data object *will* reside at address 0 and
> thus taking its address will result in a pointer that has all its bits
> clear. Obviously that pointer then should not be equal to NULL, since
> it was obtained by taking the address of a valid object, that is, the
> pointer indeed points to something. Therefore,
> 
> int *a = &first_object;
> int *b = (int *) 0;
> 
> must result in different values in a and b. Will it?

Yes.

"6.3.2.3 Pointers

If a null pointer constant is converted to a pointer type, the
resulting pointer, called a null pointer, is guaranteed to compare
unequal to a pointer to any object or function."

This implies that a linker cannot place an object at address zero.

> my problem is not that the program was not
> correct. It wasn't and I have admitted it from the beginning. My problem
> was that the compiler removed a test on an assumption. It could not
> *prove* that the pointer was not NULL. It merely *assumed* it. It can
> argue that what I did was wrong, but then it should have told me so.

Now you're just starting to make things up!  Undefined behaviour does
not require the compiler to issue a diagnostic.  Anything can happen;
as the saying goes, demons might fly out of your nose.  (This phrase
is from the canonical comp.lang.c explanation of undefined behaviour;
no-one expects demons to fly out of anyone's nose, but the C standard
does not forbid it.)

>> In practice that's a lot harder than you might think.  If we were to
>> issue a warning for every transformation we made based on the
>> semantics of the C language I'm sure people would complain.  "You
>> can't dereference a NULL pointer" is a fundamental part of the
>> language.
> 
> I think I see where your semantics and mine are different:
> 
> You say: "You can't dereference a NULL pointer"
> 
> I say: "You shouldn't dereference a NULL pointer"

The important semantics are neither yours nor mine, but these:

3.4.3
undefined behavior:

behavior, upon use of a nonportable or erroneous program construct or
of erroneous data, for which this International Standard imposes no
requirements

NOTE Possible undefined behavior ranges from ignoring the situation
completely with unpredictable results, to behaving during translation
or program execution in a documented manner characteristic of the
environment (with or without the issuance of a diagnostic message), to
terminating a translation or execution (with the issuance of a
diagnostic message).

EXAMPLE An example of undefined behavior is the behavior on integer
overflow.

Andrew.

Re: Serious code generation/optimisation bug (I think)

[Paweł Sikora]

On Wednesday 28 of January 2009 17:39:39 Andrew Haley wrote:
> Zoltán Kócsi wrote:
> >> No, this is since C90; nothing has changed in this area.  NULL
> >> doesn't mean "address 0", it means "nothing".  The C statement
> >>
> >>   if (ptr)
> >>
> >> doesn't mean "if ptr does not point to address zero", it means "if ptr
> >> points to something".
> >
> > A question then:
> >
> > How can I make a pointer to point to the integer located at address
> > 0x0?
>
> Didn't we address this before?  You can't.

do you say that we can't write a valid/defined program in C for
e.g. arm architercture? on some arms, the object (vector interrupt table)
starts at adress 0x0.

Re: Request for testing/help for the LTO branch

[Joe Buck]

On Wed, Jan 28, 2009 at 05:11:51AM -0800, Rainer Orth wrote:
> Rafael Espindola writes:
> 
> > > I suppose you mis-parsed my question: Solaris and IRIX *are* ELF targets
> > > (just not Linux, so using the system linker, not GNU ld).  If I understand
> > > you correctly, they might just work (modulo bugs)?
> >
> > That should work. You still might need to extend the linker  to
> > support IL in static libraries. We can work with normal .o with the
> > modified collect2 in the branch, but for archives we need linker
> > support.
> 
> Ok, I see.  Maybe we can extend Sun ld to handle that, given that the
> sources are now open via OpenSolaris.

Or just use GNU ld on Solaris, it works.

Re: Request for testing/help for the LTO branch

[Joe Buck]

On Wed, Jan 28, 2009 at 05:18:13AM -0800, Rainer Orth wrote:
> But at least on Solaris, using GNU ld is sort of a problem: there are lots
> of GCC testsuite regressions right now, and GNU ld doesn't support several
> of Sun ld's advanced features, which is why I very much prefer to use the
> native linker if at all possible.

In my work I haven't encountered any need for "advanced features", so I'm
curious about what Sun ld features you rely on that aren't suported by
GNU ld.

Re: Request for testing/help for the LTO branch

[Rainer Orth]

Joe Buck writes:

> > Ok, I see.  Maybe we can extend Sun ld to handle that, given that the
> > sources are now open via OpenSolaris.
> 
> Or just use GNU ld on Solaris, it works.

My testing indicates otherwise, apart from the lack of support for some
newer Solaris features.

Rainer

Re: Request for testing/help for the LTO branch

[Eric Botcazou]

> My testing indicates otherwise, apart from the lack of support for some
> newer Solaris features.

I presume it's again the combination Sun as + GNU ld?

-- 
Eric Botcazou

Re: New GCC Runtime Library Exception: not fit for purpose

[Ian Lance Taylor]

Joern Rennecke  writes:

> The definition of 'independent module' is such that it does not include files
> that make no use of any runtime interfaces at all.  E.g. a newlib file
> is an independent module if it uses a multiply and that multiply is
> implemented as a libgcc function all by gcc, but if the multiply is
> implemented by gcc with straightline assembly code, and there is no other
> use of the Runtime library in this file, it will not qualify.
> There are likely a large number of files in newlib that will not have a
> Runtime library dependence at all on any target.

I'm not sure what your point is here.  newlib is not under the GPL in
any case.  It is not affected by the gcc runtime library license.


> Note that there is also code which is not written in a high level language
> which uses gcc runtime library interfaces.  For example, look at
> libgloss/m68k/crt0.S , which uses __do_global_dtors .
> That the license of libgloss is GPL-compatible does not help here,
> since we want to allow people to link programs containing non-GPL-compatible
> code simultanously against libgloss and libgcc.

I don't see anything which prohibits them from doing so.

The runtime library license says that you can link libgcc with
proprietary code, whether that proprietary code was compiled with gcc
or whether it was compiled with some non-gcc proprietary compiler.
What the runtime library license restricts is linking libgcc with
proprietary code which was compiled by a mix of gcc and proprietary
code to produce some program, and then distributing the program
without distributing source code.

Ian

Re: New GCC Runtime Library Exception

[Mark Mitchell]

Joseph S. Myers wrote:

> Is the full wording of a sample copyright/license header that should go in 
> all affected GCC source files available? 

I will check on this.  I think I may have something from the FSF about
that; if not, we'll figure out what to do.

> Do I understand correctly that all FSF-copyright files (more than ten 
> lines long) distributed by GCC that go into runtime libraries used by 
> GCC-compiled code, except those shared with outside projects such as glibc 
> and Classpath (but including e.g. the non-Classpath files in libjava, and 
> those files in libiberty that presently have license exceptions), should 
> use the new wording? 

I don't know about libjava, but certainly libstdc++, libgcc, libgomp,
and so forth should get the new exception.

> (But that e.g. Makefiles building the libraries 
> should use GPLv3+ without any exception, and tm.h headers should not have 
> the exception even though they provide a few macros for libgcc.)

Yes, except that I think tm.h headers should have the exception too, if
they are used in libgcc.

> Will the transition to use GPLv3+exception need to be made on release 
> branches before any more releases are made from them (so that if anyone 
> should volunteer to the SC to make any further 4.2 releases, before the 
> point at which I propose to close 4.2 branch in the absence of such a 
> volunteer, they will need to ensure the transition patch is backported)?

We should just update the licenses on the trunk.  The change from GPLv2
to GPLv3 in the midst of the 4.2.x release cycle was confusing to
people.  I see no reason to do that again.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

RFC: case insensitive for #include

[H.J. Lu]

Hi,

I got a request to try "FOO.H" if foo.h doesn't exist when dealing
with

#include "foo.h"

Any comments?

Thanks.

-- 
H.J.

Re: RFC: case insensitive for #include

[David Daney]

H.J. Lu wrote:

Hi,

I got a request to try "FOO.H" if foo.h doesn't exist when dealing
with

#include "foo.h"

Any comments?



How about "Foo.h", "FOo.H", etc.?

I have found as many errors with mixed case screw-ups as with the 
'single case' variety you mention.


Would you want to make it fully case insensitive or only try the 
lower->upper case?


David Daney

Re: RFC: case insensitive for #include

[H.J. Lu]

On Wed, Jan 28, 2009 at 12:03 PM, David Daney  wrote:
> H.J. Lu wrote:
>>
>> Hi,
>>
>> I got a request to try "FOO.H" if foo.h doesn't exist when dealing
>> with
>>
>> #include "foo.h"
>>
>> Any comments?
>>
>
> How about "Foo.h", "FOo.H", etc.?
>
> I have found as many errors with mixed case screw-ups as with the 'single
> case' variety you mention.
>

When case insensitive include is enabled, there are no differences
among "foo.h", "FOO.H", "Foo.h", "FOo.H". It will be user's responsibility
to name his/her files properly.


-- 
H.J.

Re: RFC: case insensitive for #include

[Chris Lattner]

On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote:


Hi,

I got a request to try "FOO.H" if foo.h doesn't exist when dealing
with

#include "foo.h"

Any comments?


I strongly recommend against this, unless this is only a "last chance"  
fall back.


From a performance standpoint, if you have -Idir1 -Idir2 -Idir3, you  
don't want to stat all variants of "foo.h" in dir1 before moving on to  
dir2.  If you do a full search for foo.h in all appropriate search  
paths, and then redo it only on failure, then the performance issue  
goes away.  However, in that  case you get very difficult to explain  
behavior if you have multiple files with spelling variants of foo.h in  
different search paths.


-Chris

Re: RFC: case insensitive for #include

[H.J. Lu]

On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner  wrote:
>
> On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote:
>
>> Hi,
>>
>> I got a request to try "FOO.H" if foo.h doesn't exist when dealing
>> with
>>
>> #include "foo.h"
>>
>> Any comments?
>
> I strongly recommend against this, unless this is only a "last chance" fall
> back.
>
> From a performance standpoint, if you have -Idir1 -Idir2 -Idir3, you don't
> want to stat all variants of "foo.h" in dir1 before moving on to dir2.  If
> you do a full search for foo.h in all appropriate search paths, and then
> redo it only on failure, then the performance issue goes away.  However, in
> that  case you get very difficult to explain behavior if you have multiple
> files with spelling variants of foo.h in different search paths.
>

I won't stat all variants of "foo.h". I think scandir will work here and
this feature will be supported only if scandir is available.

-- 
H.J.

Re: RFC: case insensitive for #include

[Ian Lance Taylor]

"H.J. Lu"  writes:

> I got a request to try "FOO.H" if foo.h doesn't exist when dealing
> with
>
> #include "foo.h"
>
> Any comments?

Please, no.

They could use header.gcc instead.

http://gcc.gnu.org/onlinedocs/cppinternals/Files.html

Ian

Re: RFC: case insensitive for #include

[David Daney]

H.J. Lu wrote:

On Wed, Jan 28, 2009 at 12:21 PM, Chris Lattner  wrote:

On Jan 28, 2009, at 11:51 AM, H.J. Lu wrote:


Hi,

I got a request to try "FOO.H" if foo.h doesn't exist when dealing
with

#include "foo.h"

Any comments?

I strongly recommend against this, unless this is only a "last chance" fall
back.

From a performance standpoint, if you have -Idir1 -Idir2 -Idir3, you don't
want to stat all variants of "foo.h" in dir1 before moving on to dir2.  If
you do a full search for foo.h in all appropriate search paths, and then
redo it only on failure, then the performance issue goes away.  However, in
that  case you get very difficult to explain behavior if you have multiple
files with spelling variants of foo.h in different search paths.



I won't stat all variants of "foo.h". I think scandir will work here and
this feature will be supported only if scandir is available.



And would you preemptivly scan all include directories and flatten all 
names found, or would you only do it on failure to find the name as 
written (i.e. could you address Chris' question)?


David Daney

CGEN-generated files vs GPL

[DJ Delorie]

What are the implications (GPL-wise) of using CGEN-generated files in
gcc?  Specifically, I'm working on a second attempt to contribute the
MeP port, and its intrinsics are CGEN-generated (and there are a *lot*
of them - most opcodes have an intrinsic).  I'd rather not have to
manually enter all that info twice (there are VLIW tags, latency info,
etc - for each intrinsic)

Re: RFC: case insensitive for #include

[H.J. Lu]

On Wed, Jan 28, 2009 at 12:32 PM, Ian Lance Taylor  wrote:
> "H.J. Lu"  writes:
>
>> I got a request to try "FOO.H" if foo.h doesn't exist when dealing
>> with
>>
>> #include "foo.h"
>>
>> Any comments?
>
> Please, no.
>
> They could use header.gcc instead.
>
> http://gcc.gnu.org/onlinedocs/cppinternals/Files.html
>

Will it work on pathnames?

Thanks.


-- 
H.J.

Re: RFC: case insensitive for #include

[Ian Lance Taylor]

"H.J. Lu"  writes:

> On Wed, Jan 28, 2009 at 12:32 PM, Ian Lance Taylor  wrote:
>> "H.J. Lu"  writes:
>>
>>> I got a request to try "FOO.H" if foo.h doesn't exist when dealing
>>> with
>>>
>>> #include "foo.h"
>>>
>>> Any comments?
>>
>> Please, no.
>>
>> They could use header.gcc instead.
>>
>> http://gcc.gnu.org/onlinedocs/cppinternals/Files.html
>>
>
> Will it work on pathnames?

Normally the file is placed where the header file lives, and gives
alternate names which may be used to open the header file.

Ian

Re: RFC: case insensitive for #include

[H.J. Lu]

On Wed, Jan 28, 2009 at 12:48 PM, Ian Lance Taylor  wrote:
> "H.J. Lu"  writes:
>
>> On Wed, Jan 28, 2009 at 12:32 PM, Ian Lance Taylor  wrote:
>>> "H.J. Lu"  writes:
>>>
 I got a request to try "FOO.H" if foo.h doesn't exist when dealing
 with

 #include "foo.h"

 Any comments?
>>>
>>> Please, no.
>>>
>>> They could use header.gcc instead.
>>>
>>> http://gcc.gnu.org/onlinedocs/cppinternals/Files.html
>>>
>>
>> Will it work on pathnames?
>
> Normally the file is placed where the header file lives, and gives
> alternate names which may be used to open the header file.
>

Say I have

#include "Foo/Foo.h"

I want to map it to foo/foo.h on disk. Can I map Foo to foo with
header.gcc in directory, foo?

Thanks.


-- 
H.J.

Re: RFC: case insensitive for #include

[Ian Lance Taylor]

"H.J. Lu"  writes:

> Say I have
>
> #include "Foo/Foo.h"
>
> I want to map it to foo/foo.h on disk. Can I map Foo to foo with
> header.gcc in directory, foo?

Yes.  Put this at top level (i.e., in the same directory where the
directory "foo" is):

Foo/Foo.h foo/foo.h

Then #include "Foo/Foo.h" will open foo/foo.h.

You do have to compile with the -remap option.

Ian

Re: New GCC Runtime Library Exception: amendment proposal

[Robert Dewar]

Joern Rennecke wrote:


1. Grant of Additional Permission.

You have permission to propagate a work of Target Code formed by  
combining the Runtime Library with Independent Modules, even if such  
propagation would otherwise violate the terms of GPLv3, provided that  
all Target Code was eithwe generated by Eligible Compilation  
Processes. You may then convey such a combination under terms of your  
choice, consistent with the licensing of the Independent Modules.


I must say i do not like the language "violate the terms of GPLv3".
This is a license, you can't violate the terms, since the license
does not force you to do anything, it merely permits you to do
certain things.

I think it would be much clearer to say "otherwise not be covered by
the terms of GPLv3"

Re: Serious code generation/optimisation bug (I think)

[Robert Dewar]

Zoltán Kócsi wrote:


You say: "You can't dereference a NULL pointer"

I say: "You shouldn't dereference a NULL pointer"


Yes, but the standard says can't in effect, and gives
no idea of what it might mean to dereference a null
pointer.


I shouldn't but I most certainly can. I can generate a NULL pointer
where the compiler can not prove (at compile time) that it is NULL. 
If I dereference it, then whatever happens is my problem. 


Indeed, according to the C standard, anything can happen, since the
program is undefined, so you should not be complaining about the
program behaving in a particular way.


I should not
do that but I can and if I do, I take the consequences. 


You saw the legitimate consequences, and you don't like them,
so you don't really mean this.


The compiler,
in my opinion, must not assume that just because something should not
be done it can not possibly be done. Actually, it should not assume
things at all. Rather, it should prove things before making a
transformation. If it makes a transformation based on nothing more 
than its assumptions, then at least it should give me a warning.


The compiler is free to make any transformation that has the property
that if the program is defined C, then the transformation will not
affect the defined semantics. It is fine from a language point of
view for a transformation to have any effect at all on an undefined
program.


See my problem?


You are thinking about things at the wrong level, you have some
notion that the C you write is transformed in a manner you understand
into machine language, but there is no such guarantee, the only
guarantee is that the resulting binary program implements the
semantics of the program if the execution is defined.


Zoltan

Re: Serious code generation/optimisation bug (I think)

[Robert Dewar]

Paweł Sikora wrote:


do you say that we can't write a valid/defined program in C for
e.g. arm architercture? on some arms, the object (vector interrupt table)
starts at adress 0x0.


If 0 is a valid address, then it is improper for the compiler to use
0 to represent the null pointer. You may have in mind the idea that
the null pointer has a representation of all zero bits, but there is
no such requirement or suggestion in the C language.

Re: Serious code generation/optimisation bug (I think)

[Erik Trulsson]

On Wed, Jan 28, 2009 at 04:39:39PM +, Andrew Haley wrote:
> Zoltán Kócsi wrote:
> >> No, this is since C90; nothing has changed in this area.  NULL
> >> doesn't mean "address 0", it means "nothing".  The C statement
> >>
> >>   if (ptr)
> >>
> >> doesn't mean "if ptr does not point to address zero", it means "if ptr
> >> points to something".
> > 
> > A question then:
> > 
> > How can I make a pointer to point to the integer located at address
> > 0x0?
> 
> Didn't we address this before?  You can't.
> 
> > It is a perfectly valid object, it exists, therefore I should be
> > able to get its address? In fact, if I have a CPU that starts its data
> > RAM at 0, then the first data object *will* reside at address 0 and
> > thus taking its address will result in a pointer that has all its bits
> > clear. Obviously that pointer then should not be equal to NULL, since
> > it was obtained by taking the address of a valid object, that is, the
> > pointer indeed points to something. Therefore,
> > 
> > int *a = &first_object;
> > int *b = (int *) 0;
> > 
> > must result in different values in a and b. Will it?
> 
> Yes.
> 
> "6.3.2.3 Pointers
> 
> If a null pointer constant is converted to a pointer type, the
> resulting pointer, called a null pointer, is guaranteed to compare
> unequal to a pointer to any object or function."
> 
> This implies that a linker cannot place an object at address zero.

Wrong.  There is nothing which requires a null pointer to be all-bits-zero
(even though that is by far the most common representation of null
pointers.)

Consider for example the following code sequence:

  int a;
  int *p, *np;
  a=0;
  p = (int*) a; /* a is not a null pointer constant */
  np = (int *) 0;   /* 0 is a null pointer constant */

After running that code 'np' will be a null pointer, while it is
implementation defined if 'p' is a null pointer or not.
It would be perfectly legal for a compiler to define that code to mean that
'p' is a pointer to address zero, while 'np' is a null pointer which
internally happens to have the same representation as an int with the value
0xdeadbeef.
(On such a system it would of course not be possible to place any real
object at the address 0xdeadbeef since a null pointer does not point to any
real object, but would seem unlikely to be a major problem.)



-- 

Erik Trulsson
ertr1...@student.uu.se

Re: CGEN-generated files vs GPL

[Frank Ch. Eigler]

DJ Delorie  writes:

> What are the implications (GPL-wise) of using CGEN-generated files in
> gcc?  Specifically, I'm working on a second attempt to contribute the
> MeP port, and its intrinsics are CGEN-generated (and there are a *lot*
> of them - most opcodes have an intrinsic).  [...]

My understanding is that since CGEN constitutes a mechanical
translation process, it cannot change the copyright situation of the
underlying human-written input file.  (The extent to which CGEN's own
source code is being copied into the output is trivial and is
disclaimed by the cgen's bison-based license.)

- FChE

Re: CGEN-generated files vs GPL

[Joseph S. Myers]

On Wed, 28 Jan 2009, DJ Delorie wrote:

> What are the implications (GPL-wise) of using CGEN-generated files in
> gcc?  Specifically, I'm working on a second attempt to contribute the
> MeP port, and its intrinsics are CGEN-generated (and there are a *lot*
> of them - most opcodes have an intrinsic).  I'd rather not have to
> manually enter all that info twice (there are VLIW tags, latency info,
> etc - for each intrinsic)

I believe the source code (i.e., what you'd change to modify the 
intrinsics) needs including in the GCC release tarballs.  I don't think 
CGEN itself needs including, any more than OCaml needs including because 
the ARM NEON intrinsic generators are written in OCaml.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: New GCC Runtime Library Exception

[Joseph S. Myers]

On Wed, 28 Jan 2009, Mark Mitchell wrote:

> > (But that e.g. Makefiles building the libraries 
> > should use GPLv3+ without any exception, and tm.h headers should not have 
> > the exception even though they provide a few macros for libgcc.)
> 
> Yes, except that I think tm.h headers should have the exception too, if
> they are used in libgcc.

The tm.h headers are a lot of essentially host-side code with a few macros 
such as LIBGCC2_LONG_DOUBLE_TYPE_SIZE that affect target-side code in some 
cases.  But if we should add the exception to over 8 lines of code 
(the amount of config/*.h and config/*/*.h headers currently under GPLv3, 
which may not be the exact set of tm.h headers) for the sake of those 
macros, we can of course do so.

(Ideally the host-side and target-side tm.h headers would be separate with 
the latter being in the libgcc directory and only defining those macros 
needed on the target side, but that's a much more involved change.)

> > Will the transition to use GPLv3+exception need to be made on release 
> > branches before any more releases are made from them (so that if anyone 
> > should volunteer to the SC to make any further 4.2 releases, before the 
> > point at which I propose to close 4.2 branch in the absence of such a 
> > volunteer, they will need to ensure the transition patch is backported)?
> 
> We should just update the licenses on the trunk.  The change from GPLv2
> to GPLv3 in the midst of the 4.2.x release cycle was confusing to
> people.  I see no reason to do that again.

Does this mean the transition does not block 4.4 branching and if no-one 
has volunteered to prepare a patch and got the patch ready by the time 4.4 
branches it should just go on trunk for 4.5?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Request for testing/help for the LTO branch

[H.J. Lu]

On Tue, Jan 27, 2009 at 1:24 PM, H.J. Lu  wrote:
> On Tue, Jan 27, 2009 at 1:11 PM, Diego Novillo  wrote:
>> The LTO branch is starting to get some semblance of stability, though
>> is by no means in any kind of mergeable state.  I have updated the
>> wiki page to reflect the current status (Simon, Rafael, Doug, Cary,
>> please make sure I haven't missed anything substantial):
>>
>> http://gcc.gnu.org/wiki/LinkTimeOptimization
>>
>> Essentially, the biggest areas where we need help are:
>>
>> - Testing on other targets.  We have only tested on x86 (32 and 64
>> bit) targets.  I'm pretty sure other targets are either non-functional
>> or show major breakage.  We'd appreciate any daily tester that could
>> include the branch and report bugs to bugzilla (feel free to assign to
>> me).
>>
>
> I can try to run tests on Linux/ia32, Linux/ia64 and Linux/x86-64. Does it
> require gold? It will be nice if gold can be installed along with ld and
> gcc can check/pick the appropriate linker.

On Linux/ia32, my result with revision 143742 is different from

http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02939.html

I have extra failures and extra passes:


-- New failures:
FAIL: 21_strings/basic_string/numeric_conversions/char/stod.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stof.cc execution test
FAIL: 21_strings/basic_string/numeric_conversions/char/stold.cc execution test
FAIL: 22_locale/locale/cons/12352.cc execution test
FAIL: 23_containers/vector/bool/modifiers/insert/31370.cc execution test
FAIL: 25_algorithms/heap/moveable.cc execution test
FAIL: 25_algorithms/next_permutation/1.cc execution test
FAIL: 25_algorithms/nth_element/1.cc execution test
FAIL: 25_algorithms/partial_sort/1.cc execution test
FAIL: 25_algorithms/partial_sort/moveable.cc execution test
FAIL: 25_algorithms/prev_permutation/1.cc execution test
FAIL: 27_io/basic_filebuf/overflow/char/13858.cc execution test
FAIL: 27_io/basic_filebuf/overflow/wchar_t/13858.cc execution test
FAIL: 27_io/basic_filebuf/sync/char/9182-1.cc execution test
FAIL: 27_io/basic_ios/exceptions/char/2.cc execution test
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/hash_no_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/priority_queue_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_data_map_rand.cc execution test
FAIL: ext/pb_ds/regression/tree_no_data_map_rand.cc execution test
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\mfac\M" 4
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\mfib\M" 5
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\mpow2m1\M" 4
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\msq_sum\M" 4
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\msum\M" 4
FAIL: tr1/2_general_utilities/enable_shared_from_this/not_shared2.cc
execution test
FAIL: tr1/2_general_utilities/enable_shared_from_this/not_shared3.cc
execution test
FAIL: tr1/2_general_utilities/enable_shared_from_this/not_shared.cc
execution test
FAIL: tr1/3_function_objects/function/2.cc execution test
FAIL: tr1/3_function_objects/function/3.cc execution test
FAIL: tr1/3_function_objects/function/9.cc execution test

New passes:
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\\mfac\\M" 4
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\\mfib\\M" 5
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\\mpow2m1\\M" 4
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\\msq_sum\\M" 4
FAIL: gcc.dg/tree-ssa/tailrecursion-5.c scan-tree-dump-times optimized
"\\msum\\M" 4

H.J.

Re: New GCC Runtime Library Exception

[Mark Mitchell]

Joseph S. Myers wrote:

> The tm.h headers are a lot of essentially host-side code with a few macros 
> such as LIBGCC2_LONG_DOUBLE_TYPE_SIZE that affect target-side code in some 
> cases.  But if we should add the exception to over 8 lines of code 
> (the amount of config/*.h and config/*/*.h headers currently under GPLv3, 
> which may not be the exact set of tm.h headers) for the sake of those 
> macros, we can of course do so.

Yes.  It's not like this is some big loophole; it's unlikely that you
can do anything proprietary with tm.h files.  The bottom line is that
the run-time libraries need to be free of any GPLv3 code that doesn't
have the exception to avoid frightening people.  That's critical.

> (Ideally the host-side and target-side tm.h headers would be separate with 
> the latter being in the libgcc directory and only defining those macros 
> needed on the target side, but that's a much more involved change.)

Indeed.  And, of course, once the libgcc bits are split out, then we
should remove the exception from the tm.h files.

> Does this mean the transition does not block 4.4 branching and if no-one 
> has volunteered to prepare a patch and got the patch ready by the time 4.4 
> branches it should just go on trunk for 4.5?

I think this change should be part of 4.4.  I was planning to work on
some of the patch bits myself, and to ask others to volunteer for some
of the other bits.

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: CGEN-generated files vs GPL

[DJ Delorie]

> I believe the source code (i.e., what you'd change to modify the
> intrinsics) needs including in the GCC release tarballs.  I don't
> think CGEN itself needs including, any more than OCaml needs
> including because the ARM NEON intrinsic generators are written in
> OCaml.

The same cgen files produce all the binutils tools as well; they're
currently in src/cgen/cpu/mep-* although they (1) should be in
src/cpu/* and (2) need to be trimmed (the vendor has asked that the
default configuration be core-only).

Alternatively, a copy of just the one *.cpu file could be added to
gcc, but that would mean maintaining the same file in two places.

src/cgen is 3.7M; src/cpu is 1.5M

Re: CGEN-generated files vs GPL

[Joseph S. Myers]

On Wed, 28 Jan 2009, DJ Delorie wrote:

> > I believe the source code (i.e., what you'd change to modify the
> > intrinsics) needs including in the GCC release tarballs.  I don't
> > think CGEN itself needs including, any more than OCaml needs
> > including because the ARM NEON intrinsic generators are written in
> > OCaml.
> 
> The same cgen files produce all the binutils tools as well; they're
> currently in src/cgen/cpu/mep-* although they (1) should be in
> src/cpu/* and (2) need to be trimmed (the vendor has asked that the
> default configuration be core-only).
> 
> Alternatively, a copy of just the one *.cpu file could be added to
> gcc, but that would mean maintaining the same file in two places.

Copying that one file is I think the minimum needed so the GCC tarball 
contains sources for the software it distributes.

-- 
Joseph S. Myers
jos...@codesourcery.com

incorrect license on some gcc/*.c files?

[Ben Elliston]

After reading about the new runtime license, I did some grepping through
the gcc/ directory to see how many files would need updating.  I was
surprised to discover three files that are part of GCC proper, but are
still under GPLv2.  Shouldn't these all be GPLv3?

M  tree-parloops.c
M  ipa-struct-reorg.c
M  ipa-struct-reorg.h

If so, I have a patch and will submit it.

Ben

Re: incorrect license on some gcc/*.c files?

[Richard Guenther]

On Wed, Jan 28, 2009 at 11:29 PM, Ben Elliston  wrote:
> After reading about the new runtime license, I did some grepping through
> the gcc/ directory to see how many files would need updating.  I was
> surprised to discover three files that are part of GCC proper, but are
> still under GPLv2.  Shouldn't these all be GPLv3?
>
> M  tree-parloops.c
> M  ipa-struct-reorg.c
> M  ipa-struct-reorg.h
>
> If so, I have a patch and will submit it.

Yes, they should be v3.

Richard.

> Ben
>
>
>

gcc-4.2-20090128 is now available

[gccadmin]

Snapshot gcc-4.2-20090128 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090128/
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/branches/gcc-4_2-branch 
revision 143743

You'll find:

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

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

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

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

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

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

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

gcc-testsuite-4.2-20090128.tar.bz2The GCC testsuite

Diffs from 4.2-20090121 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.

Re: New GCC Runtime Library Exception

[Joseph S. Myers]

On Wed, 28 Jan 2009, Mark Mitchell wrote:

> Joseph S. Myers wrote:
> 
> > The tm.h headers are a lot of essentially host-side code with a few macros 
> > such as LIBGCC2_LONG_DOUBLE_TYPE_SIZE that affect target-side code in some 
> > cases.  But if we should add the exception to over 8 lines of code 
> > (the amount of config/*.h and config/*/*.h headers currently under GPLv3, 
> > which may not be the exact set of tm.h headers) for the sake of those 
> > macros, we can of course do so.
> 
> Yes.  It's not like this is some big loophole; it's unlikely that you
> can do anything proprietary with tm.h files.  The bottom line is that
> the run-time libraries need to be free of any GPLv3 code that doesn't
> have the exception to avoid frightening people.  That's critical.

Then there are other files beyond tm.h that are included in libgcc code 
that need the exception adding, such as coretypes.h and include/ansidecl.h 
(via tconfig.h).

Then there are lots of other miscellaneous license issues: files that have 
been added with GPLv2 on the host side since the main transition was done, 
host side files (in libiberty in particular) that haven't been 
transitioned to GPLv3, files over 10 lines with no copyright or license 
notices (some quite large, some probably on the target side as well as the 
host side), the GFDL revision in the manual not being the most current one 
(and the set of Invariant Sections in the manual not being those the FSF 
wanted there as of five years ago and put in the last printed edition), 
  I don't know what issues are or are not considered how critical.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: New GCC Runtime Library Exception

[Mark Mitchell]

Joseph S. Myers wrote:

> Then there are lots of other miscellaneous license issues: files that have 
> been added with GPLv2 on the host side since the main transition was done, 

>   I don't know what issues are or are not considered how critical.

Let's not turn this into a complete license audit.  Let's face it: in a
project as big as GCC, there are certain to be some files with incorrect
notices.  The FSF is very clearly on record as to what they intend the
license to be; the actual notices matter, but the intent is clear.

Fixing the other issues is of course general goodness, but the FSF isn't
going to sue anybody because we forgot to fix some random header
included through various levels of indirection and thus someone could
make a claim that some part of libgcc is missing the exception.  And no
judge is likely to uphold such a claim.

Just finding the files that currently have an exception and updating
them to the new exception -- a single, uniform exception across the
source tree -- is going to be a big win.

Thanks,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: CGEN-generated files vs GPL

[Joe Buck]

On Wed, Jan 28, 2009 at 02:05:45PM -0800, Joseph S. Myers wrote:
> On Wed, 28 Jan 2009, DJ Delorie wrote:
> 
> > What are the implications (GPL-wise) of using CGEN-generated files in
> > gcc?  Specifically, I'm working on a second attempt to contribute the
> > MeP port, and its intrinsics are CGEN-generated (and there are a *lot*
> > of them - most opcodes have an intrinsic).  I'd rather not have to
> > manually enter all that info twice (there are VLIW tags, latency info,
> > etc - for each intrinsic)
> 
> I believe the source code (i.e., what you'd change to modify the
> intrinsics) needs including in the GCC release tarballs.  I don't think
> CGEN itself needs including, any more than OCaml needs including because
> the ARM NEON intrinsic generators are written in OCaml.

I agree.  The GPL says that the source code is defined as the preferred
form for modification: including only the generated C code would be a
GPL violation.

I think it should be handled in the same way that bison parsers are
handled: put both the input and the output in release tarballs, etc.
There's no more reason to include cgen than to include bison.

Re: New GCC Runtime Library Exception

[Joe Buck]

On Wed, Jan 28, 2009 at 11:17:27AM -0800, Mark Mitchell wrote:

> > lines long) distributed by GCC that go into runtime libraries used by
> > GCC-compiled code, except those shared with outside projects such as glibc
> > and Classpath (but including e.g. the non-Classpath files in libjava, and
> > those files in libiberty that presently have license exceptions), should
> > use the new wording?
> 
> I don't know about libjava, but certainly libstdc++, libgcc, libgomp,
> and so forth should get the new exception.

I think we need FSF guidance on how to handle "the non-Classpath files in
libjava", given that they wanted to handle Classpath differently.

gcc 4.4.0 loop-unrolling optimizations peculiarity observed

[martin krastev]

gcc version: powerpc-apple-darwin8.11.0-gcc-4.4.0 (GCC) 4.4.0 20090116
(experimental)
version is a macports (formerly darwin ports) build of gcc4.4.0 on an
OSX 10.4.11 ppc7450 host

Following C function produces different code depending on the use of
'loop_Ai' vs 'direct_assignment_Ai' snippets:

float a[4][4] __attribute__ ((aligned (16)));
float b[4][4] __attribute__ ((aligned (16)));

float c[4][4] __attribute__ ((aligned (16)));

inline static void
mmul(
float (&c)[4][4],
const float (&a)[4][4],
const float (&b)[4][4])
{
// iterate by product's rows
for (unsigned i = 0; i < 4; i++)
{
register float ai[4][4];

// swizzle each element of the i-th row of A into a
full-dimensional vector
for (unsigned j = 0; j < 4; j++)

// direct_assignment_Ai:
/*  ai[j][0] = ai[j][1] = ai[j][2] = ai[j][3] = a[i][j];
*/
// loop_Ai:
for (unsigned k = 0; k < 4; k++)
ai[j][k] = a[i][j];

// multiply the first element of the i-th row of A by the first row of B
for (unsigned k = 0; k < 4; k++)
{
c[i][k] = ai[0][k] * b[0][k];
}

// multiply-add all subsequent elements of the i-th row of A
by their respective rows of B
for (unsigned j = 1; j < 4; j++)
{
for (unsigned k = 0; k < 4; k++)
{
c[i][k] += ai[j][k] * b[j][k];
}
}
}
}

/code

Observed ~10% performance degradation when using 'loop_Ai' instead of
'direct_assignment_Ai'. From what I can tell, the differences in the
generated ppc code constitute mainly instruction scheduling.

Following optimization-related compiler options were used for the test:

-fno-exceptions -fno-rtti -faltivec -maltivec -mtune=7450 -O3
-fmessage-length=0 -funroll-loops -ffast-math -fstrict-aliasing
-ftree-vectorize -ftree-vectorizer-verbose=3 -fvisibility=hidden
-fvisibility-inlines-hidden -fno-threadsafe-statics

Full test app code and resulting .s files available upon request. For
the record, the intended vectorization fails, so resulting code is
entirely scalar, but it is rich on fused multiply-add's.

-martin

sizeof in initializer expression not working as expected

[Bruce Korb]

Hi,

I was trying to figure out how come a memory allocation was short.
I think I've stumbled onto the issue.  "evt_t" is a 48 byte structure
and "tpd_uptr" is a uintptr_t.  "sz" initializes to 52 (decimal).
The value would be correct if I were not trying to multiply the
size of the pointer by 4.  The result should be 64.

Below is a fragment of a GDB session:

79  size_t sz = sizeof (evt_t) + (4 * sizeof (tpd_uptr));
(gdb) n
85  if (sv_name == NULL) sv_name = (char *)null_z;
(gdb) p sizeof(evt_t)
$15 = 48
(gdb) p (4 * sizeof (tpd_uptr))
$16 = 16
(gdb) p (sizeof (evt_t) + (4 * sizeof (tpd_uptr)))
$17 = 64
(gdb) p sz
$18 = 52
(gdb) set sz = 64
(gdb) p sz
$19 = 64

Here is the compiler information:

$ /usr/bin/gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The code was compiled -O0.  Yes, I know the compiler is old.
It is required for the work I am doing.  Oh, if it makes a difference:

static inline void
do_emit_snap_comments_set_event(
char const * sv_name,  tpd_u32 sv_id, tpd_u32 vv_id,
char const * comments)
{
size_t sz = sizeof (evt_t) + (4 * sizeof (tpd_uptr));
evt_t* evt;

I did look into http://gcc.gnu.org/bugzilla but nothing jumped out.
Thanks for any suggestions!

Regards, Bruce

Void Pointer Alignment - GCC 3.4.6

[Rohit Arul Raj]

Hi All,

I am working with GCC 3.4.6 for a private target. The Alignment of all
pointer variables in my target is supposed to be 16bits. But it seems
that for void pointers, the alignment by default is taken as 8 bits. I
have defined the following macros to get the desired alignment but
still it doesn't seem to work.

#define Pmode HImode
#define POINTER_SIZE 16

Are there any other macros that are supposed to be defined to get the
preferred alignment or any other way of implementing this?

Regards,
Rohit

Re: Void Pointer Alignment - GCC 3.4.6

[Ian Lance Taylor]

Rohit Arul Raj  writes:

> I am working with GCC 3.4.6 for a private target. The Alignment of all
> pointer variables in my target is supposed to be 16bits. But it seems
> that for void pointers, the alignment by default is taken as 8 bits. I
> have defined the following macros to get the desired alignment but
> still it doesn't seem to work.
>
> #define Pmode HImode
> #define POINTER_SIZE 16
>
> Are there any other macros that are supposed to be defined to get the
> preferred alignment or any other way of implementing this?

Alignment is not set based on the size, though that often determines a
default value.  It is set based on macros in the CPU.h file, like
BIGGEST_ALIGNMENT, DATA_ALIGNMENT, LOCAL_ALIGNMENT,
STACK_SLOT_ALIGNMENT, etc.  See the internals documentation.

Ian

Re: Void Pointer Alignment - GCC 3.4.6

[Rohit Arul Raj]

On Thu, Jan 29, 2009 at 11:39 AM, Ian Lance Taylor  wrote:
> Rohit Arul Raj  writes:
>
>> I am working with GCC 3.4.6 for a private target. The Alignment of all
>> pointer variables in my target is supposed to be 16bits. But it seems
>> that for void pointers, the alignment by default is taken as 8 bits. I
>> have defined the following macros to get the desired alignment but
>> still it doesn't seem to work.
>>
>> #define Pmode HImode
>> #define POINTER_SIZE 16
>>
>> Are there any other macros that are supposed to be defined to get the
>> preferred alignment or any other way of implementing this?
>
> Alignment is not set based on the size, though that often determines a
> default value.  It is set based on macros in the CPU.h file, like
> BIGGEST_ALIGNMENT, DATA_ALIGNMENT, LOCAL_ALIGNMENT,
> STACK_SLOT_ALIGNMENT, etc.  See the internals documentation.
>
> Ian
>

Hi,

Previously i had written a simple test case:

void *a, *b, *c ;
int fun()
{
  temp(a, b, c);
}

and set breakpoints at the function definitions of the DATA_ALIGNMENT,
LOCAL_ALIGNMENT in cpu.h but it doesn't seem to hit the break points.

BIGGEST_ALIGNMENT is set to 16 and i have not yet defined STACK_SLOT_ALIGNMENT.

Regards,
Rohit