On Fri, 14 Mar 2008, Paul Brook wrote:
> I you have several of these you might want to consider adding an
> effective-target check that uses a compile test rather than guessing from
> commandline options. c.f. check_effective_target_arm32 and
> check_effective_target_arm_vfp_ok.
Note the issue
On Fri, 2008-03-14 at 10:21 -0700, Janis Johnson wrote:
> On Fri, 2008-03-14 at 10:18 -0500, Joel Sherrill wrote:
>
> > /* { dg-skip-if "" { *-*-* } { "-mcpu=405" } { "-mcpu=" } } */
> >
> > I think this is doing what we want it to. It looks like it results
> > the tests getting run when -mcpu=40
On Fri, 2008-03-14 at 10:18 -0500, Joel Sherrill wrote:
> /* { dg-skip-if "" { *-*-* } { "-mcpu=405" } { "-mcpu=" } } */
>
> I think this is doing what we want it to. It looks like it results
> the tests getting run when -mcpu=405 and excluded when
> -mcpu=603e is set on the board cflags.
The te
On Fri, 14 Mar 2008, Joel Sherrill wrote:
> If you all think this is the right approach, ack me and I will
> get the powerpc cases done first and submit a patch for review.
Janis will need to confirm the right approach.
The aim is:
* If no -mcpu option in the multilib flags, run the test (with
Joseph S. Myers wrote:
On Thu, 13 Mar 2008, Joel Sherrill wrote:
Also, if you use a multilib option in testing, that option goes on the
command line *after* the options specified in dg-options. The tests may
need to use dg-skip-if to skip them if any CPU option other than the one
in the tes
On Friday 14 March 2008, Joseph S. Myers wrote:
> On Thu, 13 Mar 2008, Joel Sherrill wrote:
> > > Also, if you use a multilib option in testing, that option goes on the
> > > command line *after* the options specified in dg-options. The tests
> > > may need to use dg-skip-if to skip them if any CP
On Thu, 13 Mar 2008, Joel Sherrill wrote:
> > Also, if you use a multilib option in testing, that option goes on the
> > command line *after* the options specified in dg-options. The tests may
> > need to use dg-skip-if to skip them if any CPU option other than the one
> > in the test is explicit
Joseph S. Myers wrote:
On Wed, 12 Mar 2008, David Edelsohn wrote:
Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networking or disk?
Joel
Jan Hubicka wrote:
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Joseph S. Myers wrote:
On Wed, 12 Mar 2008, David Edelsohn wrote:
Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networking or disk?
Joel
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Look at check_vmx_hw_availa
On Wed, 12 Mar 2008, David Edelsohn wrote:
> > Joel Sherrill writes:
>
> Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
>
> Joel> Are those things which would be expected to fail on a vanilla
> Joel> 603e target without networking or disk?
>
> Joel> Is this another cate
> David Edelsohn wrote:
> >>Joel Sherrill writes:
> >>
> >
> >Joel> Those all look like checks to see if the compiler itself
> >Joel> supports Altivec -- not a run-time check on the hardware
> >Joel> like the Neon check_effective_target_arm_neon_hw appears
> >Joel> to be.
> >
>
> Joel Sherrill writes:
Joel> FAIL: gcc.target/powerpc/405-mullhw-1.c scan-assembler mullhw
Joel> Are those things which would be expected to fail on a vanilla
Joel> 603e target without networking or disk?
Joel> Is this another category of tests to avoid somehow?
405-mullhw-1.c is i
David Edelsohn wrote:
Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Look at check_vmx_hw_availa
> Joel Sherrill writes:
Joel> Those all look like checks to see if the compiler itself
Joel> supports Altivec -- not a run-time check on the hardware
Joel> like the Neon check_effective_target_arm_neon_hw appears
Joel> to be.
Look at check_vmx_hw_available again.
David
On Wednesday 12 March 2008, Joel Sherrill wrote:
> Paul Brook wrote:
> >> Since we are talking 100s of tests, it seems like it would be
> >> easiest to avoid them in the scripts. I just don't know how
> >> to do that.
> >
> > You might want to look at how the ARM NEON vector unit is handled
> > (ch
David Edelsohn wrote:
Joel Sherrill writes:
Joel> If I understand this correctly, it is checking that the
Joel> target HW actually supports the Neon extension.
Joel> Is this right?
Joel> Where does this get invoked?
Joel> I think I am on the edge of understanding a solution
Joel>
> Joel Sherrill writes:
Joel> If I understand this correctly, it is checking that the
Joel> target HW actually supports the Neon extension.
Joel> Is this right?
Joel> Where does this get invoked?
Joel> I think I am on the edge of understanding a solution
Joel> path. It sounds like I need to
Paul Brook wrote:
Since we are talking 100s of tests, it seems like it would be
easiest to avoid them in the scripts. I just don't know how
to do that.
You might want to look at how the ARM NEON vector unit is handled
(check_effective_target_arm_neon_ok and check_effective_target_arm_neon_
> Since we are talking 100s of tests, it seems like it would be
> easiest to avoid them in the scripts. I just don't know how
> to do that.
You might want to look at how the ARM NEON vector unit is handled
(check_effective_target_arm_neon_ok and check_effective_target_arm_neon_hw).
Paul
H.J. Lu wrote:
On Wed, Mar 12, 2008 at 09:13:07AM -0700, Andrew Pinski wrote:
On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
10022a: f2 0f 10 c0 movsd %xmm0,%xmm0
Is there any way to skip these tests for particular HW features
that are
On Wed, Mar 12, 2008 at 09:13:07AM -0700, Andrew Pinski wrote:
> On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill
> <[EMAIL PROTECTED]> wrote:
>
> >
> > 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0
> >
> > Is there any way to skip these tests for particular HW features
> > that are n
On Wed, Mar 12, 2008 at 9:09 AM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
>
> 10022a: f2 0f 10 c0 movsd %xmm0,%xmm0
>
> Is there any way to skip these tests for particular HW features
> that are not present? There are similar failures on the PowerPC
> target I use for repo
Richard Guenther wrote:
On Wed, Mar 12, 2008 at 4:23 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
Hi,
Did the default i386 CPU model that gcc generates
code for change between 4.2.x and 4.3.0? I didn't
see anything in the release notes that jumps out at
me about this.
Using i386-rtems
> Hi,
>
> Did the default i386 CPU model that gcc generates
> code for change between 4.2.x and 4.3.0? I didn't
> see anything in the release notes that jumps out at
> me about this.
There wasnt any intend to change the codebase. However the default
tunning now has changed to "generic" model.
On Wed, Mar 12, 2008 at 4:23 PM, Joel Sherrill
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Did the default i386 CPU model that gcc generates
> code for change between 4.2.x and 4.3.0? I didn't
> see anything in the release notes that jumps out at
> me about this.
>
> Using i386-rtems4.9 as the targe
Hi,
Did the default i386 CPU model that gcc generates
code for change between 4.2.x and 4.3.0? I didn't
see anything in the release notes that jumps out at
me about this.
Using i386-rtems4.9 as the target, I was running
code compiled by gcc 4.3.0 on a vanilla i386 and
was getting illegal ins
28 matches
Mail list logo
