Deprecating Itanium1 for GCC 4.4

Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

Hello,

I would like to propose that support for Itanium1 be deprecated for
GCC 4.4 and removed for GCC 4.5.

I doubt there are many Itanium 1 machines left in use (production or
even for hobbyists). The only Itanium1 that reached the market was the
Merced, AFAIK. But only a few 1000s of these were sold, in 2000/2001.
Most of them are probably not running anymore, and the ones still
working probably don't run ia64-linux so they don't need GCC.

On the other side of the equation: The Itanium1 machine description
accounts for ~15% of the total ia64 back-end code, and it's probably
not very well tested. Both GCC and binutils are defaulted to tune for
Itanium 2 processors, so generating code for Itanium1 requires the
-mtune=itanium1 option. I can't find any test results in
gcc-testresults reported with -mtune=itanium1 [1]. Those people who
still use Itanium1 are probably better off if they  stick with the
older GCC releases (pre-gcc-3.4) because at least back then, Itanium1
received maybe some testing (there were regressions reported against
gcc 3.4, for example, by H.J. Lu).

I understand that removing the back end is a big hammer.  On the other
hand, this discussion has come up before, ~5 years ago (see e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15653#c18) and basically
nothing has happened since then.

It seems to me that removing obviously-unused code from a back end
that already perhaps doesn't get as much attention as it needs, is a
good idea...
Thoughts?

Ciao!
Steven


[1] http://gcc.gnu.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&q=itanium1&ul=%2Fml%2Fgcc-testresults%2F%25

Re: Deprecating Itanium1 for GCC 4.4

[Richard Guenther]

On Sun, Mar 15, 2009 at 5:16 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Hello,
>
> I would like to propose that support for Itanium1 be deprecated for
> GCC 4.4 and removed for GCC 4.5.
>
> I doubt there are many Itanium 1 machines left in use (production or
> even for hobbyists). The only Itanium1 that reached the market was the
> Merced, AFAIK. But only a few 1000s of these were sold, in 2000/2001.
> Most of them are probably not running anymore, and the ones still
> working probably don't run ia64-linux so they don't need GCC.
>
> On the other side of the equation: The Itanium1 machine description
> accounts for ~15% of the total ia64 back-end code, and it's probably
> not very well tested. Both GCC and binutils are defaulted to tune for
> Itanium 2 processors, so generating code for Itanium1 requires the
> -mtune=itanium1 option. I can't find any test results in
> gcc-testresults reported with -mtune=itanium1 [1]. Those people who
> still use Itanium1 are probably better off if they  stick with the
> older GCC releases (pre-gcc-3.4) because at least back then, Itanium1
> received maybe some testing (there were regressions reported against
> gcc 3.4, for example, by H.J. Lu).
>
> I understand that removing the back end is a big hammer.  On the other
> hand, this discussion has come up before, ~5 years ago (see e.g.
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15653#c18) and basically
> nothing has happened since then.
>
> It seems to me that removing obviously-unused code from a back end
> that already perhaps doesn't get as much attention as it needs, is a
> good idea...
> Thoughts?

I think it is sensible to deprecate Itanium1 for 4.4.

Thanks,
Richard.

> Ciao!
> Steven
>
>
> [1] http://gcc.gnu.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&q=itanium1&ul=%2Fml%2Fgcc-testresults%2F%25
>

Re: Deprecating Itanium1 for GCC 4.4

[Joseph S. Myers]

Note that I do not propose to add this sort of substantial target-specific 
code change to my patch to remove deprecated targets/features 
<http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00527.html> (currently 
pending review for 4.5); I'll leave such removals to target maintainers 
(just as I did not remove all the Unicos/Mk code that's still present in 
the Alpha back end when removing deprecated target/features for 4.4, 
leaving that to the Alpha maintainers).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Sun, Mar 15, 2009 at 6:08 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> Note that I do not propose to add this sort of substantial target-specific
> code change to my patch to remove deprecated targets/features
> <http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00527.html> (currently
> pending review for 4.5); I'll leave such removals to target maintainers
> (just as I did not remove all the Unicos/Mk code that's still present in
> the Alpha back end when removing deprecated target/features for 4.4,
> leaving that to the Alpha maintainers).

Right.

Should it be agreed that deprecating Itanium1 is a good idea, then of
course I'll take care of removing the code for it, but I would do it
at the end of the GCC 4.5 development cycle.

Does that make sense?

Ciao!
Steven

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Sun, Mar 15, 2009 at 5:16 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> Hello,
>
> I would like to propose that support for Itanium1 be deprecated for
> GCC 4.4 and removed for GCC 4.5.

...and in case folks wonder why this comes up now:

1. Bootstrap with -mtune=itanium1 fails

2. Testing with a non-bootstrap build shows that *all* test cases fail
at -O3 (probably the selective scheduler wasn't tested for itanium1)

Ciao!
Steven

Re: Deprecating Itanium1 for GCC 4.4

[Gerald Pfeifer]

On Sun, 15 Mar 2009, Steven Bosscher wrote:
> I doubt there are many Itanium 1 machines left in use (production or
> even for hobbyists). The only Itanium1 that reached the market was the
> Merced, AFAIK. But only a few 1000s of these were sold, in 2000/2001.
> Most of them are probably not running anymore, and the ones still
> working probably don't run ia64-linux so they don't need GCC.

Itanium 1 is less than marginal as far as Itanium goes.  For example,
a quick check indicates that both SLES 9 (released in summer 2004)
and RHEL 4 (released half a year later) have Itanium 2 as the minimum
requirement.

I have a hard time seeing anyone use this in production, and given
the large engery and space consumption most of these machines had,
even hobbiest use.

In any case, we should not hobble GCC for the sake of one or two
hobbyists...

> I can't find any test results in gcc-testresults reported with 
> -mtune=itanium1 [1].

...especially if theye do not even contribute test results or 
feedback when things are broken (as in this case).  Deprecating
Itanium 1 with GCC 4.4 sounds very reasonable.

Gerald

Re: Deprecating Itanium1 for GCC 4.4

[Joel Sherrill]

Gerald Pfeifer wrote:
> On Sun, 15 Mar 2009, Steven Bosscher wrote:
>   
>
>> I can't find any test results in gcc-testresults reported with 
>> -mtune=itanium1 [1].
>>     
>
> ...especially if theye do not even contribute test results or 
> feedback when things are broken (as in this case).  Deprecating
> Itanium 1 with GCC 4.4 sounds very reasonable.
>
>   
Isn't the lack of recent test results one of the primary
triggers on deprecation?

And the hardware being unavailable and no current
interest being another?

This would certainly seem to match those criteria.
> Gerald
>   


--joel

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Sun, Mar 15, 2009 at 9:39 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
>> I can't find any test results in gcc-testresults reported with
>> -mtune=itanium1 [1].
>
> ...especially if theye do not even contribute test results or
> feedback when things are broken (as in this case).  Deprecating
> Itanium 1 with GCC 4.4 sounds very reasonable.

Very well. Like so?
I'll propose something for gcc-4.4/changes.html too, after this is
approved in some form.

Ciao!
Steven



	* config/ia64/ia64.c (ia64_handle_option): Inform user that Itanium1
	support is deprecated if the -mtune value is set to an Itanium1
	variant.

Index: config/ia64/ia64.c
===================================================================
--- config/ia64/ia64.c	(revision 144970)
+++ config/ia64/ia64.c	(working copy)
@@ -5212,6 +5212,8 @@ fix_range (const char *const_str)
 static bool
 ia64_handle_option (size_t code, const char *arg, int value)
 {
+  static bool warned_merced_deprecated = false;
+
   switch (code)
     {
     case OPT_mfixed_range_:
@@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
 	  if (!strcmp (arg, processor_alias_table[i].name))
 	    {
 	      ia64_tune = processor_alias_table[i].processor;
+	      if (ia64_tune == PROCESSOR_ITANIUM
+		  && ! warned_merced_deprecated)
+		{
+		  inform ("value %<%s%> for -mtune= switch is deprecated", arg);
+		  inform ("GCC 4.4 is the last release with Itanium1 support");
+		  warned_merced_deprecated = true;
+		}
 	      break;
 	    }
 	if (i == pta_size)

Re: Deprecating Itanium1 for GCC 4.4

[Andi Kleen]

Steven Bosscher <stevenb.gcc@gmail.com> writes:

>      case OPT_mfixed_range_:
> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>  	  if (!strcmp (arg, processor_alias_table[i].name))
>  	    {
>  	      ia64_tune = processor_alias_table[i].processor;
> +	      if (ia64_tune == PROCESSOR_ITANIUM
> +		  && ! warned_merced_deprecated)
> +		{
> +		  inform ("value %<%s%> for -mtune= switch is deprecated", arg);
> +		  inform ("GCC 4.4 is the last release with Itanium1 support");

"... with Itanium1 tuning support"? 

I assume it will be still possible to generate executables that work
there, just not tuned. iirc there are new instructions in I2, but I
assume you don't plan to drop the code to not generate those, just the
scheduling descriptions.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Fri, Mar 20, 2009 at 10:31 AM, Andi Kleen <andi@firstfloor.org> wrote:
> Steven Bosscher <stevenb.gcc@gmail.com> writes:
>
>>      case OPT_mfixed_range_:
>> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>>         if (!strcmp (arg, processor_alias_table[i].name))
>>           {
>>             ia64_tune = processor_alias_table[i].processor;
>> +           if (ia64_tune == PROCESSOR_ITANIUM
>> +               && ! warned_merced_deprecated)
>> +             {
>> +               inform ("value %<%s%> for -mtune= switch is deprecated", arg);
>> +               inform ("GCC 4.4 is the last release with Itanium1 support");
>
> "... with Itanium1 tuning support"?
>
> I assume it will be still possible to generate executables that work
> there, just not tuned. iirc there are new instructions in I2, but I
> assume you don't plan to drop the code to not generate those, just the
> scheduling descriptions.

I plan to drop both.

Ciao!
Steven

Re: Deprecating Itanium1 for GCC 4.4

[H.J. Lu]

On Fri, Mar 20, 2009 at 4:10 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Fri, Mar 20, 2009 at 10:31 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> Steven Bosscher <stevenb.gcc@gmail.com> writes:
>>
>>>      case OPT_mfixed_range_:
>>> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>>>         if (!strcmp (arg, processor_alias_table[i].name))
>>>           {
>>>             ia64_tune = processor_alias_table[i].processor;
>>> +           if (ia64_tune == PROCESSOR_ITANIUM
>>> +               && ! warned_merced_deprecated)
>>> +             {
>>> +               inform ("value %<%s%> for -mtune= switch is deprecated", arg);
>>> +               inform ("GCC 4.4 is the last release with Itanium1 support");
>>
>> "... with Itanium1 tuning support"?
>>
>> I assume it will be still possible to generate executables that work
>> there, just not tuned. iirc there are new instructions in I2, but I
>> assume you don't plan to drop the code to not generate those, just the
>> scheduling descriptions.
>
> I plan to drop both.
>

It would be hard to find a working Itanium 1 machine. Mine died a few years
ago.

-- 
H.J.

Re: Deprecating Itanium1 for GCC 4.4

[NightStrike]

On Fri, Mar 20, 2009 at 7:10 AM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Fri, Mar 20, 2009 at 10:31 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> Steven Bosscher <stevenb.gcc@gmail.com> writes:
>>
>>>      case OPT_mfixed_range_:
>>> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>>>         if (!strcmp (arg, processor_alias_table[i].name))
>>>           {
>>>             ia64_tune = processor_alias_table[i].processor;
>>> +           if (ia64_tune == PROCESSOR_ITANIUM
>>> +               && ! warned_merced_deprecated)
>>> +             {
>>> +               inform ("value %<%s%> for -mtune= switch is deprecated", arg);
>>> +               inform ("GCC 4.4 is the last release with Itanium1 support");
>>
>> "... with Itanium1 tuning support"?
>>
>> I assume it will be still possible to generate executables that work
>> there, just not tuned. iirc there are new instructions in I2, but I
>> assume you don't plan to drop the code to not generate those, just the
>> scheduling descriptions.
>
> I plan to drop both.

So because Itanium1 has fallen into disuse, you are dropping support
for Itanium2?  Or have I misread this?

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Fri, Mar 20, 2009 at 3:52 PM, NightStrike <nightstrike@gmail.com> wrote:
> So because Itanium1 has fallen into disuse, you are dropping support
> for Itanium2?  Or have I misread this?

You are *so* wrong it's hardly worht answering, but anyway...

Of course *NOT* remove Itanium2, duh!

But yes, remove Itanum1 scheduler descriptions and all code to not
emit Itanium2 instructions when tuning for Itanium1. Basically, all
code that is conditional on "ia64_tune == PROCESSOR_ITANIUM".

Gr.
Steven

Re: Deprecating Itanium1 for GCC 4.4

[Laurent GUERBY]

On Sun, 2009-03-15 at 17:16 +0100, Steven Bosscher wrote:
> I can't find any test results in
> gcc-testresults reported with -mtune=itanium1 [1]. Those people who
> still use Itanium1 are probably better off if they  stick with the
> older GCC releases (pre-gcc-3.4) because at least back then, Itanium1
> received maybe some testing (there were regressions reported against
> gcc 3.4, for example, by H.J. Lu).

Hi,

The compile farm machine gcc41 is a Merced based machine:

guerby@gcc41:~/build/gcc$ cat /proc/cpuinfo 
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : 7
model      : 0
model name : Merced
revision   : 6
archrev    : 0
features   : standard
cpu number : 0
cpu regs   : 4
cpu MHz    : 733.441
itc MHz    : 733.441016
BogoMIPS   : 731.13
siblings   : 1

And provides 4.4 testresults, latest looks good:

http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg02027.html

We also have a Madison machine gcc60:

guerby@gcc60:~$ cat /proc/cpuinfo 
processor  : 0
vendor     : GenuineIntel
arch       : IA-64
family     : 31
model      : 1
model name : Madison
revision   : 5
archrev    : 0
features   : branchlong
cpu number : 0
cpu regs   : 4
cpu MHz    : 1300.000
itc MHz    : 1300.000000
BogoMIPS   : 1946.41
siblings   : 1

Now I don't know if gcc41 falls in your -mtune=itanium1 category
or not.

That said if it does I don't oppose removing itanium1, we'll just turn
off the gcc41 machine when the 4.4 branch last release is done.

Sincerely,

Laurent

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Fri, Mar 20, 2009 at 5:30 PM, Laurent GUERBY <laurent@guerby.net> wrote:
> The compile farm machine gcc41 is a Merced based machine:
...
> model name : Merced
...
> Now I don't know if gcc41 falls in your -mtune=itanium1 category
> or not.

I believe it does. You may well have one of the last ones running there ;-)

However, you're not building with -mtune=itanium1, are you?

For me bootstrap fails and test results for a non-bootstrapped
compiler are really bad.

Ciao!
Steven

Re: Deprecating Itanium1 for GCC 4.4

[Laurent GUERBY]

On Fri, 2009-03-20 at 19:09 +0100, Steven Bosscher wrote:
> On Fri, Mar 20, 2009 at 5:30 PM, Laurent GUERBY <laurent@guerby.net> wrote:
> > The compile farm machine gcc41 is a Merced based machine:
> ...
> > model name : Merced
> ...
> > Now I don't know if gcc41 falls in your -mtune=itanium1 category
> > or not.
> 
> I believe it does. You may well have one of the last ones running there ;-)
> 
> However, you're not building with -mtune=itanium1, are you?
> 
> For me bootstrap fails and test results for a non-bootstrapped
> compiler are really bad.

I'm building with GCC "Debian 4.3.2-1.1" as bootstrap compiler,
CC is not defined, configure:

../trunk/configure --prefix=/n/41/guerby/install-trunk
--enable-languages=c,ada --enable-__cxa_atexit --disable-nls
--enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2

May be debian has some itanium patches.

Sincerely,

Laurent

Re : Deprecating Itanium1 for GCC 4.4

[Arthur Loiret]

2009/3/20, Laurent GUERBY <laurent@guerby.net>:
> May be debian has some itanium patches.

No, GCC in Debian doesn't have any local ia64 specific patch. :-)


Arthur.

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Fri, Mar 20, 2009 at 7:50 PM, Laurent GUERBY <laurent@guerby.net> wrote:
> I'm building with GCC "Debian 4.3.2-1.1" as bootstrap compiler,
> CC is not defined, configure:
>
> ../trunk/configure --prefix=/n/41/guerby/install-trunk
> --enable-languages=c,ada --enable-__cxa_atexit --disable-nls
> --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2
>
> May be debian has some itanium patches.

Neh, I think it means that GCC's Itanium2 code also runs OK on Merced.
Which is good news if Merced tuning is going  away ;-)

I'll retest this weekend and report the test results I find with
-mtune=itanium1. At least all -O3 test cases fail for me due to the
selective scheduler, but there where additional failures at other
optimization levels.

Ciao!
Steven

Re: Deprecating Itanium1 for GCC 4.4

[Steve Ellcey]

On Fri, 2009-03-20 at 00:24 +0100, Steven Bosscher wrote:
> On Sun, Mar 15, 2009 at 9:39 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> >> I can't find any test results in gcc-testresults reported with
> >> -mtune=itanium1 [1].
> >
> > ...especially if theye do not even contribute test results or
> > feedback when things are broken (as in this case).  Deprecating
> > Itanium 1 with GCC 4.4 sounds very reasonable.
> 
> Very well. Like so?
> I'll propose something for gcc-4.4/changes.html too, after this is
> approved in some form.
> 
> Ciao!
> Steven

Sorry for not chiming in sooner but I have been on Vacation.  I think
depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
reasonable.  Code generated and tuned for Itanium2 should run fine on
Itanium1 (Merced).  It won't be scheduled optimally of course, but it
should run correctly.

> 
> 
> 
> 	* config/ia64/ia64.c (ia64_handle_option): Inform user that Itanium1
> 	support is deprecated if the -mtune value is set to an Itanium1
> 	variant.
> 
> Index: config/ia64/ia64.c
> ===================================================================
> --- config/ia64/ia64.c	(revision 144970)
> +++ config/ia64/ia64.c	(working copy)
> @@ -5212,6 +5212,8 @@ fix_range (const char *const_str)
>  static bool
>  ia64_handle_option (size_t code, const char *arg, int value)
>  {
> +  static bool warned_merced_deprecated = false;
> +
>    switch (code)
>      {
>      case OPT_mfixed_range_:
> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
>  	  if (!strcmp (arg, processor_alias_table[i].name))
>  	    {
>  	      ia64_tune = processor_alias_table[i].processor;
> +	      if (ia64_tune == PROCESSOR_ITANIUM
> +		  && ! warned_merced_deprecated)
> +		{
> +		  inform ("value %<%s%> for -mtune= switch is deprecated", arg);
> +		  inform ("GCC 4.4 is the last release with Itanium1 support");
> +		  warned_merced_deprecated = true;
> +		}
>  	      break;
>  	    }
>  	if (i == pta_size)

I will approve this patch, but it should say "Itanium1 tuning support"
or something like that.  The code will run on Itanium1, just not
optimally.

Steve Ellcey
sje@cup.hp.com

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey <sje@cup.hp.com> wrote:
> I think
> depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
> reasonable.  Code generated and tuned for Itanium2 should run fine on
> Itanium1 (Merced).  It won't be scheduled optimally of course, but it
> should run correctly.
(...)
> I will approve this patch, but it should say "Itanium1 tuning support"
> or something like that.  The code will run on Itanium1, just not
> optimally.

Like so (with same changelog).  I'll commit this before the end of the
week to the gcc-4_4-branch if no-one objects. Bootstrapped and tested
on ia64 with gcc-4_4-branch.

For gcc 4.5, should I wait with posting the cleanup patch until the
end of the development cycle, or can we go ahead and clean things up
now in stage 1?

Ciao!
Steven


	* config/ia64/ia64.c (ia64_handle_option): Inform user that Itanium1
	support is deprecated if the -mtune value is set to an Itanium1
	variant.

Index: config/ia64/ia64.c
===================================================================
--- config/ia64/ia64.c	(revision 145211)
+++ config/ia64/ia64.c	(working copy)
@@ -5212,6 +5212,8 @@ fix_range (const char *const_str)
 static bool
 ia64_handle_option (size_t code, const char *arg, int value)
 {
+  static bool warned_itanium1_deprecated;
+
   switch (code)
     {
     case OPT_mfixed_range_:
@@ -5245,6 +5247,16 @@ ia64_handle_option (size_t code, const c
 	  if (!strcmp (arg, processor_alias_table[i].name))
 	    {
 	      ia64_tune = processor_alias_table[i].processor;
+	      if (ia64_tune == PROCESSOR_ITANIUM
+		  && ! warned_itanium1_deprecated)
+		{
+		  inform (0,
+			  "value %<%s%> for -mtune= switch is deprecated",
+			  arg);
+		  inform (0, "GCC 4.4 is the last release with "
+			  "Itanium1 tuning support");
+		  warned_itanium1_deprecated = true;
+		}
 	      break;
 	    }
 	if (i == pta_size)

Re: Deprecating Itanium1 for GCC 4.4

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1232 bytes --]

On Sun, 29 Mar 2009, Steven Bosscher wrote:

> On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey <sje@cup.hp.com> wrote:
> > I think
> > depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
> > reasonable.  Code generated and tuned for Itanium2 should run fine on
> > Itanium1 (Merced).  It won't be scheduled optimally of course, but it
> > should run correctly.
> (...)
> > I will approve this patch, but it should say "Itanium1 tuning support"
> > or something like that.  The code will run on Itanium1, just not
> > optimally.
> 
> Like so (with same changelog).  I'll commit this before the end of the
> week to the gcc-4_4-branch if no-one objects. Bootstrapped and tested
> on ia64 with gcc-4_4-branch.
> 
> For gcc 4.5, should I wait with posting the cleanup patch until the
> end of the development cycle, or can we go ahead and clean things up
> now in stage 1?

If the cleanup doesn't go on trunk at the same time as the deprecation 
patch goes on 4.4, the deprecation patch should go on trunk at that time 
until the cleanup is done, to avoid this being deprecated only on 4.4.  (I 
think early stage 1 is a fine time for doing the cleanup.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecating Itanium1 for GCC 4.4

[Steven Bosscher]

On Sun, Mar 29, 2009 at 4:46 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Sun, 29 Mar 2009, Steven Bosscher wrote:
>
>> On Mon, Mar 23, 2009 at 7:28 PM, Steve Ellcey <sje@cup.hp.com> wrote:
>> > I think
>> > depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
>> > reasonable.  Code generated and tuned for Itanium2 should run fine on
>> > Itanium1 (Merced).  It won't be scheduled optimally of course, but it
>> > should run correctly.
>> (...)
>> > I will approve this patch, but it should say "Itanium1 tuning support"
>> > or something like that.  The code will run on Itanium1, just not
>> > optimally.
>>
>> Like so (with same changelog).  I'll commit this before the end of the
>> week to the gcc-4_4-branch if no-one objects. Bootstrapped and tested
>> on ia64 with gcc-4_4-branch.
>>
>> For gcc 4.5, should I wait with posting the cleanup patch until the
>> end of the development cycle, or can we go ahead and clean things up
>> now in stage 1?
>
> If the cleanup doesn't go on trunk at the same time as the deprecation
> patch goes on 4.4, the deprecation patch should go on trunk at that time
> until the cleanup is done, to avoid this being deprecated only on 4.4.  (I
> think early stage 1 is a fine time for doing the cleanup.)

Okeydokey.  I've put the patch with the notification on trunk and on
the 4.4 branch. I have also added a note to the web pages (see below).
 I'll work on cleaning up the Itanium1 bits asap.

Ciao!
Steven

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.4/changes.html,v
retrieving revision 1.64
diff -u -r1.64 changes.html
--- changes.html	1 Apr 2009 06:17:44 -0000	1.64
+++ changes.html	1 Apr 2009 19:52:41 -0000
@@ -98,6 +98,8 @@
       <li>2BSD on PDP-11 (pdp11-*-bsd)</li>
       <li>AIX 4.1 and 4.2 on PowerPC (rs6000-ibm-aix4.[12]*,
         powerpc-ibm-aix4.[12]*)</li>
+      <li>Tuning support for Itanium1 (Merced) variants.  Note that
+        Code tuned Itanium2 should also run correctly on Itanium1.</li>
     </ul>

     </li>