4.4 deprecation proposals

[Joseph S. Myers]

We need to consider what targets and other features, if any, to
deprecate or remove in GCC 4.4.

I previously suggested the deprecation or removal of protoize and
fixproto , without
any comments or objections being made, and have now disabled fixproto
for almost all targets that were using it.  The following targets
remain using fixproto: hppa[12]*-*-hpux10*, mips-sgi-irix[56]*,
pdp11-*-bsd, rs6000-ibm-aix4.[12]* | powerpc-ibm-aix4.[12]*.  I
propose that we deprecate "all targets using fixproto" for 4.4.  That
is, some time before 4.4 branches any of these targets still using
fixproto would be placed on the deprecation list, and removal from it
would require stopping a target from using fixproto (for example,
making fixincludes add all necessary prototypes applicable to the
target being undeprecated, or simply removing the use of fixproto if
no such prototypes need to be added).  fixproto could be removed from
trunk either when the targets are added to the deprecation list, or
when deprecated targets are removed after 4.4.0 is released.  (Note
that hppa[12]*-*-hpux10* has had 4.4 test results posted, so would not
be a deprecation candidate on the basis of being unused, and it
appears some patches have been tested on IRIX although no 4.4 test
results have been posted.)

For protoize, I propose that we do one of the following:

* Deprecate it in the 4.4 release notes (without any configure changes
  to make people use --enable-obsolete if building it, just
  documenting it as deprecated), and remove from trunk after 4.4.0 is
  released.

* Remove from trunk before 4.4 branches, on the basis that it having
  been disabled by default since
   (patch
  submission:
  ) is
  plenty of deprecation warning.  People were thinking it might be
  obsolete as of
  .

I request further comment on which of these approaches to take.

In either case, removal of support for protoize would be accompanied
by removal of support for installing the SYSCALLS.c.X file that it
uses; any externally maintained distribution would need to maintain
this and any other required files itself.  (Given that there do appear
from Google Code Search to be a few external users of the -aux-info
option, I do not propose removing it along with protoize.  We might
however consider deprecating and removing it in future, especially if
any system is implemented for exporting more structured information
about programs being compiled from GCC.)

As for target CPU deprecations, the IRA transition strategy
 indicates
the way forward.  With the plan to remove the old RA, each target will
need an IRA_COVER_CLASSES definition added to continue to work.  If
someone is willing to add this for a target, verify that the target
works with it added and fix any problems found, that will serve as
evidence that the target is still maintained (on the basis I used for
the 4.3 deprecations that either a test results posting or a patch
mentioned as testing on a target indicated it was not obsolete).  If
not, the target will not work anyway.  Thus, I propose that at the
point when the old register allocator is removed, any unconverted CPU
targets are added to the deprecation list, with removal requiring
conversion of a target to IRA.

It remains to consider the question of deprecations of target OSes or
(CPU, OS) pairs.  My only proposal here is to deprecate the generic
a.out and COFF targets where there is a corresponding ELF target; no
4.4 test results have been posted for any such targets.  The targets
affected would be:

arm-*-coff*
armel-*-coff*
h8300-*-* (generic meaning COFF only - other h8300 would remain)
i[34567]86-*-aout*
i[34567]86-*-coff*
m68k-*-aout*
m68k-*-coff*
sh-*-* (generic meaning COFF only - other sh would remain)

Where there is a catch-all -*-* meaning COFF, it could also be changed
to meaning ELF instead of removing the catch-all case.

People may of course wish to propose other OSes, individual targets or
other features for deprecation in 4.4.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: 4.4 deprecation proposals

[Manuel López-Ibáñez]

2008/6/14 Joseph S. Myers <[EMAIL PROTECTED]>:
> We need to consider what targets and other features, if any, to
> deprecate or remove in GCC 4.4.
>
> I previously suggested the deprecation or removal of protoize and
> fixproto , without

If we remove protoize, we could probably remove the
Wtraditional-conversion option, since its only use seems to be related
to protoize: http://gcc.gnu.org/onlinedocs/gcc/Protoize-Caveats.html

That would remove half of convert_arguments (c-typeck.c) and we will
have one less flag!

If a C maintainer agrees, I volunteer to write the patch.

Cheers,

Manuel.

Re: Constructing static variables in GIMPLE?

[Sean Callanan]

Dear mailing list:

I solved my own problem.  This is how I construct a static variable:

--
static tree build_static(tree type, const char* name)
{
  tree ret = NULL;

  ret = build_decl(VAR_DECL, get_identifier(name), type);

  TREE_STATIC(ret) = 1;
  assemble_variable(ret, 0, 0, 0); // tree decl, int top_level, int  
at_end, int dont_output_data

  add_referenced_var(ret);

  return ret;
}
--

By the way, this only works for static variables; for automatic  
variables, this is how I do it:


--
static tree build_automatic(tree type, const char* name)
{
  tree ret = NULL;

  ret = build_decl(VAR_DECL, get_identifier(name), type);

  DECL_ARTIFICIAL(ret) = 1; // declared by the compiler
  DECL_IGNORED_P(ret) = 1;  // no debug info
  TREE_READONLY(ret) = 0;   // writable
  DECL_EXTERNAL(ret) = 0;   // defined
  TREE_STATIC(ret) = 0; // automatic
  TREE_USED(ret) = 1;   // used
  DECL_CONTEXT(ret) = cfun->decl;

  create_var_ann(ret);
  add_referenced_var(ret);

  HOST_WIDE_INT decl_size;

  if(TYPE_SIZE(type) && TREE_CODE(TYPE_SIZE(type)) == INTEGER_CST)
{
  decl_size = tree_low_cst(TYPE_SIZE(type), 0);
}
  else
{
  decl_size = 0;
}

  rtx decl_rtl = assign_stack_local(DECL_MODE(ret), decl_size, 0);

  SET_DECL_RTL(ret, decl_rtl);

  return ret;
}
--

Sincerely,
Sean Callanan


On Jun 13, 2008, at 1:57 AM, Sean Callanan wrote:


Dear mailing list:

I am writing GCC code that constructs GIMPLE (after  
pass_apply_inline and before pass_all_optimizations) for a function- 
level static variable that gets assigned to and passed to another  
function.  My problem is that I am getting undefined symbol errors  
for a renamed version of the symbol.

I define the variable as below:

--
static tree build_static(tree type, const char* name)
{
 tree ret = NULL;

 ret = build_decl(VAR_DECL, get_identifier(name), type);

 DECL_ARTIFICIAL(ret) = 1; // declared by the compiler
 DECL_IGNORED_P(ret) = 1;  // no debug info
 TREE_READONLY(ret) = 0;   // writable
 DECL_EXTERNAL(ret) = 0;   // defined
 TREE_STATIC(ret) = 1; // static
 TREE_USED(ret) = 1;   // used
 DECL_CONTEXT(ret) = cfun->decl;

 create_var_ann(ret);
 add_referenced_var(ret);

 return ret;
}
--

Here's an example where I use this function, and demonstrating how I  
use the variable.


--
 tree last_p = build_static(long_long_unsigned_type_node, "last_p");
 // ...
 tree subtraction = build2(MINUS_EXPR, long_long_unsigned_type_node,  
end_time, start_time);

 build_gimple_modify_stmt(last_p, subtraction);
 // ...
 tree last_p_temp = create_tmp_var(TREE_TYPE(last_p),  
get_name(last_p));

 tree last_p_name = make_ssa_name(last_p_temp, NULL);
 tree last_p_assignment = build_gimple_modify_stmt(last_p_name,  
last_p);

 SSA_NAME_DEF_STMT(last_p_name) = last_p_assignment;
--

As seen above, I (try to) respect SSA when reading from this  
variable, and when assigning to it (I create an SSA_NAME when using  
the value, and assign directly to the VAR_DECL).  I'm passing an  
SSA_NAME to the function.  However, when I compile, I'm getting  
linker errors of the form:


--
[...]/test.c:4: undefined reference to `last_p.2610'
--

Oddly, I don't get undefined references for `last_p'; I find it very  
odd that it's being renamed.  Does anyone know what's going on  
here?  As always, I welcome corrections to my (admittedly novice- 
level) GIMPLE- and SSA-fu.

Thanks for looking at this.

Sincerely,
Sean Callanan

Re: [EMAIL PROTECTED]: Results for 4.4.0 20080612 (experimental) [trunk revision 136692] (GCC) testsuite on m32c-unknown-elf]

[Richard Guenther]

On Fri, 13 Jun 2008, DJ Delorie wrote:

> 
> > I should start posting these to the testing list.  Lots of m16c
> > improvements, but some m32c regressions.  I haven't tried to diagnose
> > these yet, but if nobody claims it's their fault I will ;-)
> > 
> > Anyone know why the regressions happened?
> > 
> > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O3 
> > -fomit-frame-pointer 
> > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O3 
> > -fomit-frame-pointer -funroll-loops 
> > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O3 
> > -fomit-frame-pointer -funroll-all-loops -finline-functions 
> > PASS-FAIL: gcc.c-torture/execute/builtins/vsprintf-chk.c execution,  -O3 -g 
> 
> FYI I tracked this down to this patch (r136679):
> 
> 2008-06-11  Richard Guenther  <[EMAIL PROTECTED]>
> 
>   * alias.c (get_alias_set): Use the element alias-set for arrays.
>   (record_component_aliases): For arrays and vectors do nothing.
>   * c-common.c (strict_aliasing_warning): Handle the cases
>   of alias set zero explicitly.
>   * Makefile.in (dfp.o-warn): Add -Wno-error.
> 
> Before the patch, -mcpu=m16c had execute failures for this test.
> After, -mcpu=m32c had execute failures.  The problem is in the way
> newlib is compiled, not the test case itself.
> 
> Richard, do you want me to try to track this down further, or is this
> enough for you to figure out what's happening?

I won't be able to look at this, so any help is appreciated.

Richard.