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: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.
Honza
>
>
> But cc1 should not, IMO, have to know the defaults. If you run xgcc -v
> it'll pass the right options to cc1...
>
> --
> Daniel Jacobowitz
> MontaVista Software Debian GNU/Linux Developer