This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i386-cmov1.c broken
On Sat, Jun 07, 2003 at 06:58:17PM +0200, Jan Hubicka wrote:
> > On Sat, Jun 07, 2003 at 06:38:04PM +0200, Jan Hubicka wrote:
> > > > On Sat, Jun 07, 2003 at 06:04:51PM +0200, Jan Hubicka wrote:
> > > > > > >
> > > > > > > In auditing the GCC tests, I think that gcc.dg/i386-cmov1.c is passing
> > > > > > > "by accident".
> > > > > > >
> > > > > > > In particular, this test seems to be trying to verify that the "sar"
> > > > > > > instruction is being used with "magic_namec" by scanning the assembly
> > > > > > > file.
> > > > > > >
> > > > > > > However, that's not actually happening.
> > > > > > >
> > > > > > > The scan-assembler test:
> > > > > > >
> > > > > > > /* { dg-final { scan-assembler "sar.*magic_namec" } } */
> > > > > > >
> > > > > > > which is trying to test for this is busted because "." in Tcl includes
> > > > > > > "\n", i.e., the newline character.
> > > > > > Oops, thi sis ugly. Tranks for noticing that, Mark!
> > > > > > I will fix the i386-* tests tonight.
> > > > >
> > > > > Hi,
> > > > > the failures in the tests are caused by the fact that we no longer default to
> > > > > -mcpu=k8 when -march=k8 is specified. I am testing the attached patch to
> > > > > update the SPEC files and will commit it as obivous assuming the testsuite
> > > > > passes.
> > > > >
> > > > > Daniel, I guess the other targets you've modified will need similar updates.
> > > >
> > > > if (!ix86_tune_string && ix86_arch_string)
> > > > ix86_tune_string = ix86_arch_string;
> > > > if (!ix86_tune_string)
> > > > ix86_tune_string = cpu_names [TARGET_CPU_DEFAULT];
> > > >
> > > > Blast, I thought I checked for that - you're right, -march took
> > > > precedence over the config triplet. Thanks for figuring this out.
> > > >
> > > > I'm pretty sure I got all the other targets right but I'll give them
> > > > another going-over later.
> > >
> > > There is yet another small problem in your patch I just run across.
> > > At the x86_64 cc1 used to default into k8 code generation, while it now
> > > default into i386 that makes it to just error out.
> > > When called via xgcc everything is OK, but it is somewhat anoying when
> > > you start it by hand. I am testing patch to set TARGET_CPU_DEFAULT into
> > > k8 for 64bit compiler to avoid this but the idea that cc1 now defaults
> > > into something different than xgcc looks bit unconfortable to me.
> > > At least I often call cc1 by hand and do not expect this.
> >
> > Could you explain to me how it changed? In that patch I tried not to
> > remove any mechanisms.
>
> There used to be defined TARGET_CPU_DEFAULT but it is not anymore that
> makes i386.h to default in i386 that is quite nonsential for x86-64 so
> cc1 just errors out when executed with no -march switch.
> I am not sure how did you changed this behaviour, but somehow the define
> got lost.
Oh, I know why this happened. I was concentrating on preserving the
same default settings when the driver was used, not when cc1 was used
directly. I think your patch to set the TARGET_CPU_DEFAULT for this
case is right.
Someone else is going to have to decide whether the change was a
problem. Namely, before:
- an i686-linux gcc defaulted to -mtune=i686
- an i686-linux cc1 defaulted to -mtune=i686
After:
- an i686-linux gcc defaults to -mtune=i686
- an i686-linux cc1 defaults to nothing (-mtune=i386)
This is definitely a change, but I think these defaults are the
driver's business anyway - cc1 shouldn't be smart about it.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer