GCC-3.3.5 release status

GCC-3.3.5 release status

[Gabriel Dos Reis]

Hi,

   I recall that the release date for GCC-3.3.5 is September 30, 2004.

There are currently 24 bugs open for 3.3.5.  Out of them, 6 have
critical priority but most are regressions since 3.3.1 or before. 

  rtl-optimization/12419 is assigned to Jakub, but no much activity
      has been observed since April 2004.

  target/14484, a regression since 3.1.  At this point, it is ever
      going to be fixed for 3.3.x, so it might well be closed unless
      MIPS maintainers want to look into it.

  c++/14507, a regression since 3.0.1.

  rtl-optimization/15853, a regression since 3.3.3

  rtl-optimization/16586, a regression since 3.1 also present in 3.4.x

  rtl-optimization/17363

None of the above, probably except rtl-optimization/17363, is a
showtopper for GCC-3.3.5.  I will make a prerelease sometime today.

The following bugs have been fixed in GCC-3.3.5 (those are the bugs
for which I have a PR number in the ChangeLogs; if I miss any, please
let me know).

     bootstrap/15120

     c/15549

     c++/11946
     c++/16175

     libgcj/12475

     libgfortran/15930

     libstdc++/11352

     middle-end/15930
     middle-end/16038
     rtl-optimization/14700
     rtl-optimization/14782

     target/12602
     target/13250
     target/13926
     target/15186
     target/15202
     target/15647
     target/15718
     target/16459
     target/16494
     target/16559

Bug target/15718 affected certain programs that implied complex numbers
in registers on the alpha target, and was seen as a weakness in
GCC-3.3.4. 

      
Thanks,

-- Gaby

small 'instrument-functions' patch

[Perret Yannick]

Hello,

I ask some question few days ago about modifying the
-finstrument-function behavior (this idea comes from the
fact that I built some years ago a profiler based on this
feature).

I manage to create the modification. As I'm not familiar
with how patches are managed for gcc (in particular
because it is not a bug correction but a modification of
an existing feature) I prefer first to describe the modification
and wait for indications.

Here is what it does:

this modification goal is to allow to generate calls to
__cyg_profile_func_enter with more details that are available
at compilation time.

A new option is added: -finstrument-functions-full
If activated, the "prototype" of __cyg_profile_func_enter is
changed for the following one:

__cyg_profile_func_enter(void *sym, void *call,
	                 char *fnc0, char *fnc1, char *fnc2,
			 char *file, int line, int id);
where:
  sym   is the symbol address of the function  \ same than the
  call  is the symbol address of the call site / original ones
  fnc0  is the 'level 0' name (declaration name)
  fnc1  is the 'level 1' name (scope information)
  fnc2  is the 'level 2' name (all including C++ full style)
  file  is the function's file name
  line  is the line of the function declaration in the file
  id    is the unique identifier generated by gcc for profile

The __cyg_profile_func_exit is not changed.

Of course the behavior of the -finstrument-function option is not 
modified at all.


Modifications are very smalls. Some small modifications in toplevel.c, 
opts.c,
c-opts.c and flags.h for the definition of the new option, and a new set 
of code in
function.c (expand_function_start, inside the original profiling code).


So now ? Does the new code needs to be "approved" to decide if it is 
usefull and
if it is well writen ?
Does I create a patch and send it on the list ?

Thank in advance.


Regards,
--
Yannick Perret

Re: small 'instrument-functions' patch

[James E Wilson]

Perret Yannick wrote:
> I manage to create the modification. As I'm not familiar
> with how patches are managed for gcc (in particular
> because it is not a bug correction but a modification of
> an existing feature) I prefer first to describe the modification
> and wait for indications.

There is information on our web site about contributing patches. See
     http://gcc.gnu.org/contribute.html

If it is more than about 10 lines or so, we need a copyright assignment. 
  It must follow GNU and GCC coding conventions.  It must be documented. 
  It must be tested.  Etc.

You submit a patch by sending it to the gcc-patches mailing list.  You 
then wait until it is reviewed.  There are often more patches being 
submitted than the reviewers have time to deal with, so if the patch 
isn't doing something obviously useful, there might be a wait for a review.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

GCC-3.3.5 release status

[Gabriel Dos Reis]

Hi,

  GCC-3.3.5 is going to be packaged on September 30, 2004 (i.e. in two
days).  Starting from now, the branch gcc-3_3-branch is frozen untill
I say otherwise.  

  After GCC-3.3.5, there will be GCC-3.3.6 on December 31, 2004.  That
will be the last release from the 3.3.x series.

Thanks,

-- Gaby