headers
Steve Kargl | 1 Jan 2006 03:10
Picon

gfortran 2005 year end stats

The following stats do not capture the numerous hours of 
code review, emails, bug chasing and reduction, and IRC
discussions that concern gfortran.  Although the stats
suggest that a majority of the commits and patches are due
to the effort of a small handful of individuals, in fact over
50 different individuals are credited with a patch.  In 2005,
gfortran has made tremendous strides in becoming a full
feature Fortran 95 compiler.  If the development effort can
be sustained, 2006 promises to be a significant year for 
gfortran.

Gfortran 2005 Year End Stats

374 commits in gcc/fortran
126 commits in libgfortran
350 PR's closed

(The above may not reflect all PR's related to gfortran.  For
example, middle and back end bugs reported against gfortran
may not be properly counted here.)

The condense list of commits and the PRs in gcc/fortran are:

  55  Tobias Schlueter
        16907, 18525, 18990, 19182, 19194, 19195, 19479, 19543,
        19673, 20059, 20178, 20323, 20361, 20467, 21260, 21912,
        22010, 23420, 23661, 23765, 24008, 24404, 24643
  50  Steven G. Kargl
        17792, 19168, 19589, 19754, 19936, 20058, 20786, 21257,
        21375, 23065, 23516, 24005, 24636, 24917, 25055, 25078,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Schlie | 1 Jan 2006 06:26
Picon

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

> From: Mike Stump wrote:
> On Dec 31, 2005, at 10:51 AM, Paul Schlie wrote:
>> As although C/C++ define some expressions as having undefined
>> semantics;
> 
> I'd rather it be called --do-what-i-mean.  :-)
> 
> Could you give us a hint at what all the semantics you would want to
> change with this option?  Are their any code bases that you're trying
> to compile?  Compilers that you're trying to be compatible with?

Yes, although I'd like to think of it as being:

 --do-what-i-said-given-the-semantics-specified-for-the-target

More specifically for example:

- enable the specification of a null-pointer value, and negative integer
  pointer conversions. (i.e. what does (int *)-2 + (int *)0 mean?) Thereby
  enabling a target which may concurrently map their registers to low-order
  addresses and be able define NULL as being some value other than 0.

- enable the specification of null-pointer and generalized ordered pointer
  comparison semantics. (i.e. what does *a <= *b | *c >= (int *)0 mean?)
  Thereby being able to dereference 0 as possibly being r0 without presuming
  code execution is halted or have to resort to assembler; and/or determine
  if an address is within the range of some memory region bounds without
  having to explicitly cast pointers to integers, which may not be the right
  thing to do for targets which support differently sized pointers and
  integers, or who's pointers may have different arithmetic semantics than
(Continue reading)

Permalink | Reply | 11 comments |
headers
Robert Dewar | 1 Jan 2006 08:31
Favicon

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

Gabriel Dos Reis wrote:

>Maybe that is the case for Ada; for the C or C++ standards, you'll
>have to define "good reason". 
>
>-- Gaby
>  
>
Again, I suggest that vague high level discussion is a waste of time 
here, it will be much more
productive to discuss specific examples.
Permalink | Reply | 5 comments |
headers
Gabriel Dos Reis | 1 Jan 2006 15:36

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

Robert Dewar <dewar <at> adacore.com> writes:

| Gabriel Dos Reis wrote:
| 
| >Maybe that is the case for Ada; for the C or C++ standards, you'll
| > have to define "good reason". -- Gaby
| >
| Again, I suggest that vague high level discussion is a waste of time
| here, 

I wholeheartly agree, that is why I find you need to back up your
universal claim.

-- Gaby
Permalink | Reply | 4 comments |
headers
Robert Dewar | 1 Jan 2006 16:15
Favicon

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

Gabriel Dos Reis wrote:

>Robert Dewar <dewar <at> adacore.com> writes:
>
>| Gabriel Dos Reis wrote:
>| 
>| >Maybe that is the case for Ada; for the C or C++ standards, you'll
>| > have to define "good reason". -- Gaby
>| >
>| Again, I suggest that vague high level discussion is a waste of time
>| here, 
>
>I wholeheartly agree, that is why I find you need to back up your
>universal claim.
>  
>
You mean my claim that the standards group knows what it is doing and is 
not stupid? :-)
Well I could give many examples, but I still think it is more useful to 
get back to the original intent
of Paul's thread, which is to describe specific semantics for some of 
these cases. Otherwise we
are really discussing entirely irrelevant matters.

>-- Gaby
>  
>
Permalink | Reply | 3 comments |
headers
Gabriel Dos Reis | 1 Jan 2006 17:18

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

Robert Dewar <dewar <at> adacore.com> writes:

| Gabriel Dos Reis wrote:
| 
| >Robert Dewar <dewar <at> adacore.com> writes:
| >
| >| Gabriel Dos Reis wrote:
| > | | >Maybe that is the case for Ada; for the C or C++ standards,
| > you'll
| >| > have to define "good reason". -- Gaby
| >| >
| >| Again, I suggest that vague high level discussion is a waste of time
| > | here, I wholeheartly agree, that is why I find you need to back up
| > your
| >universal claim.
| >
| You mean my claim that the standards group knows what it is doing and
| is not stupid? :-)

Your claim was this:

  # IN every case where the standard specifies undefined behavior, it
  # has a very good reason for doing so.

| Well I could give many examples,

unless "many" == "exhaustive", you'll just have wasted time and
bandwidth :-)

| but I still think it is more useful to get back to the original intent
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Dewar | 1 Jan 2006 17:56
Favicon

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

Gabriel Dos Reis wrote:

>Robert Dewar <dewar <at> adacore.com> writes:
>
>| Gabriel Dos Reis wrote:
>| 
>| >Robert Dewar <dewar <at> adacore.com> writes:
>| >
>| >| Gabriel Dos Reis wrote:
>| > | | >Maybe that is the case for Ada; for the C or C++ standards,
>| > you'll
>| >| > have to define "good reason". -- Gaby
>| >| >
>| >| Again, I suggest that vague high level discussion is a waste of time
>| > | here, I wholeheartly agree, that is why I find you need to back up
>| > your
>| >universal claim.
>| >
>| You mean my claim that the standards group knows what it is doing and
>| is not stupid? :-)
>
>Your claim was this:
>
>  # IN every case where the standard specifies undefined behavior, it
>  # has a very good reason for doing so.
>
>| Well I could give many examples,
>
>unless "many" == "exhaustive", you'll just have wasted time and
>bandwidth :-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Veksler | 1 Jan 2006 17:11
Picon
Favicon

Re: Might a -native-semantics switch, forcing native target optimization semantics, be reasonable?

I am not sure if the original poster meant the same as I do. What I have
in mind is optimizations opportunities like the one of the following
linked list:

  struct list_element 
  {
     struct list_element *p_next;
     int *p_value;
  };
  int sum_list_values(const struct list_element *p_list)
  {
     int sum=0;
     for ( ; p_list ; p_list= p_list->p_next)
       if (p_list->p_value)
         sum += *p_list->p_value;
     return sum;
  }

Now, if the programmer wants to gain 5% performance (or more), he 
might mmap /dev/zero to address 0x000000 such that
   *(*int)0 == 0

Then, the compiler or the coder could unroll the loop
to minimizes conditional branches:

  int sum_list_values(const struct list_element *p_list)
  {
     int sum=0;
     while (p_list)
     {
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Bosscher | 1 Jan 2006 18:21
Picon

RTL alias analysis

Hi rth,

The stack space sharing you added to cfgexpand.c breaks RTL alias
analysis.

For example, the attached test case breaks for pentiumpro at -O2. 
The problem apparently is that the second store to c is moved up
before before the load.
This looks like a serious problem to me...

Many thanks to Honza for crafting this test case.

Gr.
Steven

extern void abort (void) __attribute__((noreturn));

union setconflict
{
  short a[20];
  int b[10];
};

int
main ()
{
  int sum = 0;
  {
    union setconflict a;
    short *c;
(Continue reading)

Permalink | Reply | 39 comments |
headers
Frediano Ziglio | 1 Jan 2006 18:26
Picon

-fpic no optimization...


Happy 2006!

I was compiling LZMA SDK (http://www.7-zip.org/, LzmaDecode.c) and just
for curiosity I looked at output assembler. I noted that when PIC is
enabled (-fpic, Linux Intel) ebx is reserved to global pointer. However
LzmaDecode do not access any global data and do not call other functions
(no relocations at all) so why not use ebx register? -fpic make compiler
just not use ebx. I tried using different versions (gcc 3.4.4 from
Fedora Core 3 and 4.0.2 from Fedora Core 4) with same result.

Frediano Ziglio (aka freddy77)
Permalink | Reply | 2 comments |

Gmane