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.
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