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 CPU option
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
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 test
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=405 and excluded
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
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 explicitly
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
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 target, I was
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.
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
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 reporting
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 not present?
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
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
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
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 add
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
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
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
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_available
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 invoked
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
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 category of tests to
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_available
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.
25 matches
Mail list logo
