--- Comment #8 from fjahanian at apple dot com 2006-08-25 21:36 ---
I was about to sub mit the patch. Thank you for this patch.
- Fariborz
Subject: Bug 28418
Author: jsm28
Date: Fri Aug 25 21:14:24 2006
New Revision: 116436
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
GCC build triplet: apple-ppc-darwin
--- Comment #3 from fjahanian at apple dot com 2006-07-24 23:16 ---
gcc generates two separate trees for compound literals in c and c++. As in this
test case:
struct S {
int i,j;
};
void foo (struct S);
int main ()
{
foo((struct S){1,1});
}
In c it generates
--- Additional Comments From fjahanian at apple dot com 2005-09-13 21:09
---
Hello,
What is the status of Uros's patches in:
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html
Looks like they did not make it to FSF mainline? Are there remaining issues
with them?
--
http
--- Additional Comments From fjahanian at apple dot com 2005-09-13 00:52
---
Has there been any progress toward fixing the problems addressed by these PRs?
- thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22152
--- Additional Comments From fjahanian at apple dot com 2005-08-08 17:36
---
Thanks. Test case should say PR 21894.
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21894
from 3.3
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: apple-ppa-darwin
GCC host triplet: apple-ppc-darwin
GCC target triplet: apple-ppa-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21894
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs
--
What|Removed |Added
CC||dalej at apple dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20256
--
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
--- Additional Comments From fjahanian at apple dot com 2005-02-27 00:51
---
(In reply to comment #6)
The first part of the patch seems fine.
We should make tree_fold_binomial non-recursive.
You meant tree_fold_factorial? tree_fold_binomial is not recursive as is.
Note, however
of stack at -O1
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
--- Additional Comments From fjahanian at apple dot com 2005-02-25 21:32
---
Created an attachment (id=8286)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8286action=view)
A proposed patch to fix this
Note that patch I attached is against the apple-ppc-branch. So, it may not
apply
--- Additional Comments From fjahanian at apple dot com 2005-01-17 16:49
---
on apple-ppc-branch -mcpu=G5 is all you need to reproduce the problem. But I
noticed that
this bug is no longer reproducible with the FSF mainline. So, this bug has been
fixed as far as
I am concerned. Just
--- Additional Comments From fjahanian at apple dot com 2004-12-29 17:34
---
(In reply to comment #8)
Why can't we make sure that temporaries which should be aligned to 128 bits
are actually aligned to
128 bits? Surely failing to do so will cause other problems.
Yes
--- Additional Comments From fjahanian at apple dot com 2004-12-21 01:25
---
My last patch also had problems, in that it changed alignment of local vector
variables on stack.
This alignment cannot be changed because AltiVec intrincics expect 128bit
alignment. So,
I conclude that only
--- Additional Comments From fjahanian at apple dot com 2004-12-17 19:40
---
Why hasn't been there be a resolution of this PR? It seems that all issues,
including elimination of
loop numbers, etc. have been taken care of. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18792
--- Additional Comments From fjahanian at apple dot com 2004-12-18 00:43
---
Followin patch fixes the alignment problem. But it cannot be applied because it
breaks ABI
compatibilty.
A possible solution is to relax alignment of the type in question (with
alignment of 128
--- Additional Comments From fjahanian at apple dot com 2004-12-18 01:46
---
And this is the patch that I had in mind. Can this break ABI compatibily? My
limited testing shows
that it does not.
Index: rs6000.c
===
RCS
: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: apple-ppc-darwin
GCC host triplet: apple-ppc-darwin
GCC target triplet: apple-ppc-darwin
--
What|Removed |Added
CC||dje at watson dot ibm dot
||com
--- Additional Comments From fjahanian at apple dot com 2004-12-10 01:42
---
AFAICT, I don't see how gcc middle-end can force correct parameter alignment
when alignment is more
strict than PARAM_BOUNDARY. There is no code to do so (I am looking at
store_one_arg which is
the one
--- Additional Comments From fjahanian at apple dot com 2004-12-07 22:37
---
Zdenek,
Could you take a look at this?
--
What|Removed |Added
CC
--- Additional Comments From fjahanian at apple dot com 2004-12-07 23:04
---
I agree that bug is before linear loop xform. Make a slight, none-cfg change to
the test case and
loop_nbr come out different (and sequential in the nesting). Somehow, changing
the first loop
condition makes
--- Additional Comments From fjahanian at apple dot com 2004-12-06 17:55
---
I applied the patch to fsf-mainline (including darwin.h) and it worked for me.
I will do the bootstrap, dejagnu testing and let you know how it went. - Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From fjahanian at apple dot com 2004-12-06 23:32
---
David's patch (including darwin.h patch attached here) successufully
bootstrapped, dejagnu tested
on apple-ppc-darwin. Please apply the patch to mainline.
Index: darwin.h
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: apple-ppc-darwin
GCC host triplet: apple-ppc-darwin
GCC target triplet: apple-ppc-darwin
--- Additional Comments From fjahanian at apple dot com 2004-12-01 22:07
---
Regardless of how we fix this specific problem; by reverting Ulrich's patch to
find_reloads_address,
making the small change he proposed in find_reloads, or something else, there
remains the
problem each
--- Additional Comments From fjahanian at apple dot com 2004-11-29 17:15
---
This patch doesn't fix the problem I reported on apple-ppc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18118
: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: uweigand at de dot ibm dot com
ReportedBy: fjahanian at apple dot com
CC: dje at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot
org
GCC build triplet
--- Additional Comments From fjahanian at apple dot com 2004-11-17 18:02
---
Following patch has broken many dejagnu tests on apple-ppc-darwing with
-mcpu=G5.
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gccr1=1.581r2=1.582
FAIL: gcc.c-torture/execute
--- Additional Comments From fjahanian at apple dot com 2004-10-26 15:17 ---
I tested the patch on apple-ppc-darwin; bootstrapped and dejagnu tested (with and
without
-mcpu=G5). There were no regressions. This is an important bug for us. We have had 4
separate reporting of this bug
--- Additional Comments From fjahanian at apple dot com 2004-10-25 18:39 ---
I applied the last two patch, but it didn;t help:
% mygccf -O2 -mcpu=G5 -c loader_obj.i
loader_obj.c: In function 'load_obj':
loader_obj.c:92: error: unrecognizable insn:
(insn 1395 601 1396 50 (set (subreg:DI
--- Additional Comments From fjahanian at apple dot com 2004-10-25 19:12 ---
You referred to them as 'both patches' in comment #21.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15286
--- Additional Comments From fjahanian at apple dot com 2004-10-25 20:58 ---
You need to replace GET_MODE_SIZE (x) with GET_MODE_SIZE (GET_MODE (x)), etc. for a
clean
compile. But as I mentioned in last comment, I still get the ICE with or without this
patch (along
with the previous
--- Additional Comments From fjahanian at apple dot com 2004-10-25 21:14 ---
By mistake, I applied the test for !reload_completed to you earlier patch (which was
worng).
In any case,
after correcting the patch and with your latest patch, all my test cases passed. Now,
I need
to do
--- Additional Comments From fjahanian at apple dot com 2004-10-25 23:58 ---
I tried the last patch and for the following statement built with -O2 -mcpu=G5
(aaple's mixed mode)
I get the following instruction sequence. It looks OK to me. But David's case might be
different
than what I
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: apple-ppc-darwin
GCC host triplet: apple-ppc-darwin
GCC target triplet: apple-ppc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18118
it is safe
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: roger at eyesopen dot com
ReportedBy: fjahanian at apple dot com
CC: gcc
--- Additional Comments From fjahanian at apple dot com 2004-10-12 20:57 ---
tree-outof-ssa.c is not part of this patch. I accidentally checked it in. I have since
backed it out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17892
42 matches
Mail list logo
