--- Comment #2 from eres at il dot ibm dot com 2009-12-22 08:51 ---
(In reply to comment #0)
GCC trunk gets a ICE when building SPEC CPU2000 test 254.gap with -m64 -O2
-mcpu=power7 -mno-altivec -ftree-vectorize, as demonstrated by a rather large
minimized testcase that I'll attach
--- Comment #1 from eres at il dot ibm dot com 2009-12-22 08:58 ---
(In reply to comment #0)
GCC trunk gets a ICE when building SPEC CPU2000 test 173.applu and several
others with -O2 -mvsx -mno-altivec -ftree-vectorize, as demonstrated by this
-mvsx -mno-altivec should
--- Comment #1 from eres at il dot ibm dot com 2009-12-22 09:04 ---
(In reply to comment #0)
GCC trunk gets a ICE when building SPEC CPU2000 test 177.mesa with -O2 -mvsx
-mno-altivec -ftree-vectorize, as demonstrated by this minimized testcase:
-mno-altivec -mvsx should
--- Comment #6 from eres at il dot ibm dot com 2009-12-01 13:45 ---
(In reply to comment #5)
test.f works on amd64-linux on the graphite branch.
I am doing the merge of the graphite branch to trunk,
and this should be fixed then.
Running test.f using trunk -r154872 on powerpc64-suse
--- Comment #3 from eres at il dot ibm dot com 2009-10-25 11:55 ---
(In reply to comment #2)
Works for me on amd64-linux and graphite branch. See daily reports on
http://groups.google.com/group/gcc-graphite-test
No testcase was provided anyways.
Sebastian
I just tried trunk
--- Comment #10 from eres at il dot ibm dot com 2009-10-25 12:41 ---
(In reply to comment #0)
Hello!
The [patch, vectorizer] misaligned store support patch [1] resulted in more
than 10% longer execution time for Polyhedron test_fpu test on Core2.
The test is compiled with -march=x86
--- Comment #4 from eres at il dot ibm dot com 2009-10-25 14:31 ---
Created an attachment (id=18890)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18890action=view)
A testcase to reproduce the ICE
Here is the command line and the error message for the testcase attached (using
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41498
: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41499
--- Comment #1 from eres at il dot ibm dot com 2009-09-29 12:14 ---
I was using trunk -r152153 and run on powerpc64.
--
eres at il dot ibm dot com changed:
What|Removed |Added
--- Comment #14 from eres at il dot ibm dot com 2009-07-22 11:15 ---
(In reply to comment #0)
program main
implicit none
integer :: i,j
integer,parameter :: N=5000
real :: x(N)=0.0
do j=1,20
do i=1,N
x(i)=x(i)+sin(real(i))+cos(real(i))-tan(real(i))
enddo
--- Comment #9 from eres at il dot ibm dot com 2009-07-09 07:32 ---
Not using unaligned stores for this kind of data dependence or peeling
for alignment will probably help here.
The decision of how to vectorized can be changed for x86 (or any other target).
Instead of first checking
--- Comment #7 from eres at il dot ibm dot com 2009-07-05 08:12 ---
Testing test_fpu on Power7 with the power7 branch shows no significant
difference between the version compiled with the misaligned store support patch
and without it. (using -mcpu=power7 -ffast-math -funroll-loops -O3
--- Comment #35 from eres at il dot ibm dot com 2009-06-18 14:06 ---
Created an attachment (id=18021)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18021action=view)
Final version of the patch
I'll submit the following patch -- it contains Ira's latest fix and two syntax
errors
--- Comment #13 from eres at il dot ibm dot com 2009-06-15 10:41 ---
Created an attachment (id=18003)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18003action=view)
Patch to fix error in vect-42.c
Ira, thanks for the suggestion!
I deleted an extra space, so now the syntax
--- Comment #16 from eres at il dot ibm dot com 2009-06-15 13:32 ---
-/* { dg-final { scan-tree-dump-times Alignment of access forced using
versioning 3 vect { target { vect_no_align || { { !
vector_alignment_reachable} {!vect_hw_misalign} } } } } } */
+/* { dg-final { scan-tree
--- Comment #8 from eres at il dot ibm dot com 2009-06-07 07:12 ---
Created an attachment (id=17959)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17959action=view)
patch to fix syntax errors in tests
This patch should fix the syntax errors.
I'll sumbit it also if the problem
--- Comment #10 from eres at il dot ibm dot com 2009-06-07 10:51 ---
(In reply to comment #9)
The patch in comment #8 fixes the failures reported in comment #7. I now see
(powerpc-apple-darwin9 with -m64):
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect Alignment of access
--- Comment #1 from eres at il dot ibm dot com 2009-06-06 11:00 ---
It might be that i686 should be added to
check_effective_target_vect_hw_misalign.
Please try the following patch:
Index: testsuite/lib/target-supports.exp
--- Comment #3 from eres at il dot ibm dot com 2009-06-06 16:43 ---
Created an attachment (id=17957)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17957action=view)
A patch to fix the fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
--- Comment #4 from eres at il dot ibm dot com 2009-06-06 16:46 ---
(In reply to comment #3)
Created an attachment (id=17957)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17957action=view) [edit]
A patch to fix the fails
I appreciate it if you could test whether the attached
--- Comment #6 from eres at il dot ibm dot com 2009-06-06 17:32 ---
(In reply to comment #5)
With the patch in comment #3 the failures are gone:
make -k check-gcc RUNTESTFLAGS=vect.exp=*.c --target_board=unix'{,-m64}'
Thanks for checking, I'll submit the patch then.
--
http
--- Comment #5 from eres at il dot ibm dot com 2009-04-26 07:29 ---
(In reply to comment #2)
Mine. The patches which I have from the PS3 toolchain fixes this one, it is
related to PR 32110 also.
I see this problem still exits on trunk -r146794.
If you still have the patch I
--- Comment #12 from eres at il dot ibm dot com 2008-12-29 09:59 ---
(In reply to comment #11)
Isn't this fixed now? There was a new newlib release last week:
http://sourceware.org/ml/newlib/2008/msg00754.html
I'll check that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #13 from eres at il dot ibm dot com 2008-12-29 11:42 ---
(In reply to comment #11)
Isn't this fixed now? There was a new newlib release last week:
http://sourceware.org/ml/newlib/2008/msg00754.html
Yes, the problem is now fixed.
Tested on SPU with gcc version 142947
on spu-gcc
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
GCC host triplet: spu
--- Comment #9 from eres at il dot ibm dot com 2008-07-06 05:29 ---
Following http://gcc.gnu.org/ml/gcc/2008-07/msg00104.html
I would like to ask to be unassign from this bug.
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
--- Comment #19 from eres at il dot ibm dot com 2008-04-08 11:07 ---
The easiest would be to use .cfi_* assembler directives that recentish gas
supports and emitting them inline in the code, rather than creating separate
.eh_frame.
I apologize ahead if I am totally wrong about
--- Comment #6 from eres at il dot ibm dot com 2008-03-23 07:20 ---
(In reply to comment #5)
(In reply to comment #4)
I've applied a patch that should fix this. No-one's confirmed
whether it does though, so I'm marking the PR as waiting.
And I just confirmed, it does fix
: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35626
--- Comment #2 from eres at il dot ibm dot com 2008-03-07 04:52 ---
(In reply to comment #1)
What happens if you build from a clean directory?
I get the same error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #4 from eres at il dot ibm dot com 2008-03-07 05:15 ---
(In reply to comment #3)
I don't usually build in combined tree for spu-elf so I never run into this
issue. I wonder if due to the newer autoconf issue.
It seems to be related to the following change:
2008-02-20
dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35457
--- Comment #5 from eres at il dot ibm dot com 2008-02-28 13:00 ---
I can not reproduce this fail on my local x86_64-unknown-linux-gnu machine:
PASS: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
PASS: gcc.dg/tree-prof/pr34999.c execution,-fprofile-use
--- Comment #7 from eres at il dot ibm dot com 2008-02-28 13:49 ---
(In reply to comment #6)
(In reply to comment #5)
I appreciate any info on this ICE so I could try to fix it.
Sometimes --enable-checking=release triggers bugs that are hidden by other
--enable-checking settings
--- Comment #10 from eres at il dot ibm dot com 2008-02-29 05:23 ---
(In reply to comment #8)
(In reply to comment #7)
Thanks, unfortunately I still can not reproduce the fail.
Probably you need newer binutils:
GNU ld (GNU Binutils) 2.18
Yes, using a newer binutils the fail
--- Comment #1 from eres at il dot ibm dot com 2008-02-27 10:03 ---
Same error was received on powerpc64-linux, trunk r132684
configured with:
--with-cpu=default32 --enable-checking --enable-bootstrap
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35373
--- Comment #18 from eres at il dot ibm dot com 2008-02-10 07:30 ---
To further optimize this loop we would probably want to overlap the store with
subsequent loads using -fmodulo-sched; perhaps the new export-ddg can help
with
that.
I intend to test the impact of -fmodulo-sched
--- Comment #2 from eres at il dot ibm dot com 2008-01-29 16:07 ---
Created an attachment (id=15049)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15049action=view)
A patch I am currently testing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
--- Comment #1 from eres at il dot ibm dot com 2008-01-28 15:22 ---
Created an attachment (id=15037)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15037action=view)
the testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
--- Comment #3 from eres at il dot ibm dot com 2008-01-17 08:17 ---
(In reply to comment #2)
Can you show in an RTL dump why you are sure that the branch probabilities are
lost?
Sure, I am currently testing a patch we have to fix this problem,
the following '-' lines are from the SMS
--- Comment #4 from eres at il dot ibm dot com 2008-01-17 18:28 ---
A patch was committed to trunk -r131604
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34826
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34826
--- Comment #1 from eres at il dot ibm dot com 2008-01-17 07:21 ---
Created an attachment (id=14955)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14955action=view)
The testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34826
--- Comment #14 from eres at il dot ibm dot com 2008-01-10 15:05 ---
-fassociative-math and -fsigned-zeros flags can not co-exist.
I guess this testcase should be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--- Comment #16 from eres at il dot ibm dot com 2008-01-10 18:32 ---
This is because the test requires -fassociative-math for enabling the
variable-expansion as well as -fsigned-zeros for honor the sign of zero; but
they can not co-exist; also under -funsafe-math-optimizations
--- Comment #1 from eres at il dot ibm dot com 2008-01-06 15:26 ---
A patch was committed to trunk r131352.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34263
--- Comment #5 from eres at il dot ibm dot com 2007-11-30 17:24 ---
(In reply to comment #4)
That moves the stores
pS[i].x += (a[i]+b[i]);
pS[i].y += (a[i]-b[i]);
out of the inner loop, but still none of the loops are vectorized (on x86_64).
Also on ppc64
: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34263
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34223
--- Comment #2 from eres at il dot ibm dot com 2007-11-25 11:21 ---
I have been testing Zdenek's initial lim patch on SPEC2006 and tramp3d but saw
no effect on the preformance. We had an example which is similar to the
testcase shown in (http://gcc.gnu.org/ml/gcc-patches/2007-03
--- Comment #3 from eres at il dot ibm dot com 2007-11-25 14:13 ---
(In reply to comment #2)
Why is this a shift not supported:
not vectorized: relevant stmt not supported: D.1652_13 = j_29 3
Is j_29*8 supported (i.e. if you hack this expression to turn it into a
MULT_EXPR), does
-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34195
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34172
--- Comment #13 from eres at il dot ibm dot com 2007-11-16 06:52 ---
Created an attachment (id=14563)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14563action=view)
gcno (with the correct filename)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #15 from eres at il dot ibm dot com 2007-11-17 06:24 ---
(In reply to comment #14)
I still can't reproduce it. What does your gcc -v say?
Configured with: ../gcc/configure --prefix=/home/eres/check_final/build
--with-cpu=default32 --enable-checking --disable-bootstrap
--- Comment #16 from eres at il dot ibm dot com 2007-11-17 06:36 ---
(In reply to comment #15)
(In reply to comment #14)
I still can't reproduce it. What does your gcc -v say?
Configured with: ../gcc/configure --prefix=/home/eres/check_final/build
--with-cpu=default32 --enable
--- Comment #5 from eres at il dot ibm dot com 2007-11-15 12:04 ---
It seems that verify_flow_info complains about the following note,
which is generated in the partitioning phase:
(note 234 232 172 11 NOTE_INSN_SWITCH_TEXT_SECTIONS)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #7 from eres at il dot ibm dot com 2007-11-15 12:29 ---
(In reply to comment #6)
I can't reproduce this on x86*.
Again, please attach the profile information and state the exact compiler
revision you used to generate this profile information.
Sorry - I am working
--- Comment #8 from eres at il dot ibm dot com 2007-11-15 14:17 ---
When disabling rest_of_handle_reorder_blocks (bbro) the ICE disappears. (it
seems that it is not caused due to the partitioning - bbpart)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #11 from eres at il dot ibm dot com 2007-11-15 15:05 ---
Created an attachment (id=14556)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14556action=view)
File generated by -fprofile-generate
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #10 from eres at il dot ibm dot com 2007-11-15 15:02 ---
(In reply to comment #9)
I mean the files you generate with -fprofile-generate.
I expect this to be fully blamable on the partitioning code, and I would like
to work in fixing this. But you have to attach
--- Comment #12 from eres at il dot ibm dot com 2007-11-16 06:48 ---
Created an attachment (id=14562)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14562action=view)
gcda file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #1 from eres at il dot ibm dot com 2007-11-13 18:21 ---
Created an attachment (id=14545)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14545action=view)
The testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34085
--- Comment #3 from eres at il dot ibm dot com 2007-11-13 18:30 ---
Created an attachment (id=14546)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14546action=view)
the testcase (please ignore the previous testcase it has been uploaded by
mistake)
--
http://gcc.gnu.org
--- Comment #4 from eres at il dot ibm dot com 2007-11-13 18:34 ---
(In reply to comment #2)
Can you please also attach your profile information and give the exact
compiler
revision ID that you used to create that information? That way, people
without
access to POWER can still
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33711
--- Comment #1 from eres at il dot ibm dot com 2007-10-09 13:49 ---
The loop in the above example does not get vectorized because of the
subtraction in reduction; which is currently not supported.
Taken from the vectorizer dump:
test.c:19: note: worklist: examine stmt: udiff_7
--- Comment #34 from eres at il dot ibm dot com 2007-09-12 15:09 ---
I did not engage with it for some time so I doubt it if my latest version of
the patch (which is originally in
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02331.html) is suitable for
current mainline. I
--- Comment #35 from eres at il dot ibm dot com 2007-09-13 04:45 ---
Created an attachment (id=14200)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14200action=view)
lim patch
As I suspected my latest available version is not suitable for current
mainline (I attached it anyway
--- Comment #11 from eres at il dot ibm dot com 2007-09-04 12:18 ---
The patch was committed to r128075.
Revital
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
--- Comment #2 from eres at il dot ibm dot com 2007-07-11 06:51 ---
The problem seems to be fixed.
See - http://gcc.gnu.org/ml/gcc/2007-07/msg00352.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726
compiling emit-rtl.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http
--- Comment #5 from eres at il dot ibm dot com 2007-07-04 08:57 ---
You can also try to tune --param max-variable-expansions-in-unroller. The
default is to add one expansion (which seems to be the most helpful due to the
fact that adding more expansions can increase register pressure
--- Comment #8 from eres at il dot ibm dot com 2007-07-04 11:24 ---
I think c__lsm.63_30 is created during the store motion optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
--- Comment #5 from eres at il dot ibm dot com 2007-06-28 11:55 ---
(Form off-line discussion with Richard Guenther)
For-
char str[2][16] = {thisis16charslo,thisis16charslo};
On ppc64 we will get -
static char C.0[2][16] = {thisis16charslo, thisis16charslo};
while on x86_64
--- Comment #3 from eres at il dot ibm dot com 2007-06-26 07:42 ---
Created an attachment (id=13791)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13791action=view)
fix PR31150
Attached is a patch to initialize the scalar elmenets of the array
which should fix this problem.
char
--- Comment #4 from eres at il dot ibm dot com 2007-06-26 12:19 ---
There are places which checks that bsi_insert_on_edge_immediate returns
NULL so checking for NULL before calling it would change the semantic.
Here is the fix for this SIGSEGV:
Index: tree-cfg.c
--- Comment #2 from eres at il dot ibm dot com 2007-06-25 12:31 ---
I would like to be assigned to this bug.
Thanks,
Revital
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
--- Comment #5 from eres at il dot ibm dot com 2007-06-01 06:24 ---
(In reply to comment #3)
*** This bug has been marked as a duplicate of 28684 ***
Related, but a different issue.
I Agree. Bug 28684 mainly deals with the need to redefine
-funsafe-math-optimizations as IEEE
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31418
--- Comment #4 from eres at il dot ibm dot com 2007-02-26 11:46 ---
Created an attachment (id=13113)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13113action=view)
assembly file (PPC)
It seems that problem is in the initialization of the expansion
(which related to the sign
)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from eres at il dot ibm dot com 2007-02-26 13:38 ---
Created an attachment (id=13116)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13116action=view)
assembly file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30971
--- Comment #5 from eres at il dot ibm dot com 2007-02-26 13:51 ---
The reason that this tescase fails is because the expansion is been initialized
with +0, which means that it's final result will be +0 and not -0 as expected.
expansion += d -- expansion += -0 -- +0
--
http
--- Comment #6 from eres at il dot ibm dot com 2007-02-26 15:01 ---
It seems that initializing the expansion with -zero (instead of +zero)
will solve this problem.
According IEEE standard if we have -
x += something; initializing x with -0 will cause x to get the sign of
something
--- Comment #8 from eres at il dot ibm dot com 2007-02-26 18:11 ---
MVE is enabled with -funsafe-math-optimizations as it changes the order of
summation. I think it should honor signed zero, which it does not in the
current implantation. I agree that -funsafe-math-optimizations
--- Comment #3 from eres at il dot ibm dot com 2007-02-26 18:26 ---
Sure, sorry about that,-funsafe-math-optimizations is more suitable here.
The testcase also fails when -funsafe-math-optimizations is used (fsigned-zeros
is set in that case which means the testcase should not have been
--- Comment #10 from eres at il dot ibm dot com 2007-02-26 18:34 ---
I think that the way -fnsafe-math-optimization violates ieee is important.
Introducing flag_signed_zeros, as you mensioned before, enforce
-fnsafe-math-optimization to honor signed zero. So I think MVE should honor
with variable expansion optimization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm
--- Comment #1 from eres at il dot ibm dot com 2007-02-25 11:33 ---
Created an attachment (id=13105)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13105action=view)
RTL unroller's dump (compiled with -fvariable-expansion-in-unroller)
reg:DF 137 is the new variable expansion
--- Comment #2 from eres at il dot ibm dot com 2007-02-25 14:50 ---
The execution fails also when acc is float (and not double)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--- Comment #3 from eres at il dot ibm dot com 2007-02-25 14:52 ---
Created an attachment (id=13107)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13107action=view)
testcase for MVE
Running the executable of the attached testcase (compiled with MVE)
succeeded. This looks strange
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29122
--- Comment #5 from eres at il dot ibm dot com 2006-09-11 11:21 ---
Hi,
Following Dorit's comment; We thought of starting this journey with a patch
that include the cases in the vectorizer and loop-unroll and gradually add the
rest of the cases that can go under flag_reassociate_fp
--- Comment #6 from eres at il dot ibm dot com 2006-09-11 11:49 ---
I would also like to be assigned to this bug.
Thanks,
Revital
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684
98 matches
Mail list logo
