[Bug middle-end/23135] find_reloads_toplev -> find_reloads_subreg_address uses wrong reload type
--- Comment #6 from dalej at gcc dot gnu dot org 2006-04-22 00:44 --- Subject: Bug 23135 Author: dalej Date: Sat Apr 22 00:44:01 2006 New Revision: 113164 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113164 Log: 2005-04-21 Dale Johannesen <[EMAIL PROTECTED]> Radar 4506160 Bring in Joern Rennecke's fix from mainline: PR middle-end/23135 * reload.c (find_reloads_subreg_address): Pass down TYPE unchanged. Change all callers except find_reloads_toplev. Modified: branches/apple-local-200502-branch/gcc/ChangeLog.apple-ppc branches/apple-local-200502-branch/gcc/reload.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23135
[Bug target/36399] FSF GCC ABI bug on darwin/x86-32
--- Comment #4 from dalej at gcc dot gnu dot org 2009-06-04 00:06 --- Yeah. Looking through our local changes, I think you just need this line in i386.h: #define SSE_REGPARM_MAX (TARGET_64BIT ? 8 : (TARGET_MACHO ? 4 : (TARGET_SSE ? 3 : 0))) However Apple employees can't currently touch GPLv3 code, so we can't do the testing. Stan, can you do this? -- dalej at gcc dot gnu dot org changed: What|Removed |Added CC||stanshebs at earthlink dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug target/36399] FSF GCC ABI bug on darwin/x86-32
--- Comment #6 from dalej at gcc dot gnu dot org 2009-06-08 19:17 --- That needs to be parenthesized differently; if that's fixed, I have no objection to doing it that way, but since all MachO targets have SSE, that works too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36399
[Bug rtl-optimization/24930] New: Crash in combine
(in mainline) compile the below with -O. A patch follows which I'm fairly
sure is right, but I will not be able to run a test cycle until Nov 30. I'll
do it then if nobody else has.
$ld/gcc/gccs.fsf.obj/gcc/xgcc -B $ld/gcc/gccs.fsf.obj/gcc/ -O 4347034.c
4347034.c: In function 'main':
4347034.c:5: warning: incompatible implicit declaration of built-in function
'printf'
4347034.c:17: warning: incompatible implicit declaration of built-in function
'printf'
4347034.c:19: internal compiler error: in do_SUBST, at combine.c:470
int
main(int argc, char** argv)
{
if(argc == 1) {
printf("Please provide a two char argument\n");
return 0;
}
const char *buf = argv[1];
unsigned int data = (((unsigned int) buf[0]) << 8) + (unsigned int) buf[1];
if (data & 0x8000) {
data &= 0x7fff ;
data ^= 0x7fff ;
data += 1 ;
data *= -1 ;
}
printf("Data = %d\n", (int) data);
return 0;
}
Index: combine.c
===
--- combine.c (revision 107129)
+++ combine.c (working copy)
@@ -3346,13 +3346,15 @@
rtx dest = XEXP (SET_DEST (x), 0);
enum machine_mode mode = GET_MODE (dest);
unsigned HOST_WIDE_INT mask = ((HOST_WIDE_INT) 1 << len) - 1;
+ rtx or_mask;
if (BITS_BIG_ENDIAN)
pos = GET_MODE_BITSIZE (mode) - len - pos;
+ or_mask = GEN_INT (trunc_int_for_mode (src << pos, mode));
if (src == mask)
SUBST (SET_SRC (x),
- simplify_gen_binary (IOR, mode, dest, GEN_INT (src <<
pos)));
+ simplify_gen_binary (IOR, mode, dest, or_mask));
else
{
rtx negmask = gen_int_mode (~(mask << pos), mode);
@@ -3360,7 +3362,7 @@
simplify_gen_binary (IOR, mode,
simplify_gen_binary (AND, mode,
dest, negmask),
- GEN_INT (src << pos)));
+ or_mask));
}
SUBST (SET_DEST (x), dest);
--
Summary: Crash in combine
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at gcc dot gnu dot org
GCC build triplet: same
GCC host triplet: powerpc-apple-darwin
GCC target triplet: same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
[Bug rtl-optimization/24930] [4.0/4.1/4.2 Regression] Crash in combine
--- Comment #7 from dalej at gcc dot gnu dot org 2005-11-30 18:19 --- Retested on powerpc-apple-darwin and committed. -- dalej at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24930
[Bug middle-end/24950] [3.4/4.0/4.1/4.2 Regression] ICE in operand_subword_force
--- Comment #14 from dalej at gcc dot gnu dot org 2005-12-01 18:04 --- Subject: Bug 24950 Author: dalej Date: Thu Dec 1 18:04:20 2005 New Revision: 107826 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107826 Log: 2005-12-01 Alan Modra <[EMAIL PROTECTED]> Radar 4345871 ` PR middle-end/24950 * expmed.c (store_bit_field): Don't attempt to insv a field larger than the reg. Modified: branches/apple-local-200502-branch/gcc/ChangeLog.apple-ppc branches/apple-local-200502-branch/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24950
[Bug target/24323] _MM_TRANSPOSE4_PS could be improved
--- Comment #3 from dalej at gcc dot gnu dot org 2005-12-05 23:04 --- Subject: Bug 24323 Author: dalej Date: Mon Dec 5 23:04:28 2005 New Revision: 108080 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108080 Log: 2005-12-05 Dale Johannesen <[EMAIL PROTECTED]> * config/i386/xmmintrin.h (_MM_TRANSPOSE4_PS): Fix to match what was approved (PR 24323). Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/xmmintrin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24323
[Bug middle-end/25399] New: Another bogus 'clobbered by longjmp' message
(I don't think this is the same as any of the similar bugs, although I could be
wrong.)
In this case the field assignments cover all of u, so none of it is actually
live across
the call, but dataflow can't figure this out.
While this bogus warning is the only visible effect I know of, fixing this
would also
decrease register pressure and might result in improved code quality in some
cases.
struct ss { unsigned short a; unsigned short b; };
union uu { unsigned int all; struct ss parts; };
#include
extern void bar(union uu);
extern void baz();
void foo() {
for(;;)
{
union uu u;
jmp_buf env;
u.parts.a = 0;
u.parts.b = 0;
bar(u);
if (setjmp(env)==0)
baz();
else
baz();
}
}
--
Summary: Another bogus 'clobbered by longjmp' message
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.0.0
GCC host triplet: powerpc-apple-darwin8.0.0
GCC target triplet: powerpc-apple-darwin8.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25399
[Bug middle-end/25399] Another bogus 'clobbered by longjmp' message
--- Comment #3 from dalej at gcc dot gnu dot org 2005-12-13 22:54 --- (In the original example) note the bit vectors at beginning and end of blocks show 120 as live throughout the loop, although it isn't really. That's why I think it affects register pressure. GRA does do some munging of those bit vectors though, maybe it fixes this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25399
[Bug middle-end/25399] Another bogus 'clobbered by longjmp' message
--- Comment #5 from dalej at gcc dot gnu dot org 2005-12-13 23:19 ---
This slight modification shows another problem: when the message refers to an
inlined copy of a variable, it points to the inlined function body and variable
rather than the place where the problem is. In the following you get
small2.c: In function 'foo':
small2.c:9: warning: variable 'temp' might be clobbered by 'longjmp' or 'vfork'
which has proved baffling to people who've hit it: there is no 'temp' in foo,
and no 'setjmp' in the function that does contain a temp. (In the maximally
confusing case, foo could contain a completely unrelated 'temp' which is
visibly not live across a setjmp.)
struct ss { unsigned short a; unsigned short b; };
union uu { unsigned int all; struct ss parts; };
#include
extern void bar(union uu);
extern void baz();
union uu func(union uu uuin) {
union uu temp;
if (uuin.parts.b)
return uuin;
temp.parts.a = 0; temp.parts.b = 0;
return temp;
}
void foo(int i, union uu uuin) {
for(;;)
{
union uu u = func(uuin);
jmp_buf env;
bar(u);
if (setjmp(env)==0)
baz();
else
baz();
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25399
[Bug c/25449] [4.0] endless loop in nbench neural net with -ftree-loop-linear
--- Comment #1 from dalej at gcc dot gnu dot org 2005-12-16 19:26 --- Probably same as 20256. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25449
[Bug target/30582] 64-bit Darwin ABI does not support array field
--- Comment #1 from dalej at gcc dot gnu dot org 2007-01-25 18:29 --- Early drafts of the ABI spec said that, but the final version calls for passing this struct as integers. I believe the following is publicly accessible: http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/ The compiler is doing the right thing. -- dalej at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dalej at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-25 18:29:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30582
[Bug target/30582] 64-bit Darwin ABI does not support array field
--- Comment #2 from dalej at gcc dot gnu dot org 2007-01-25 18:30 --- as above -- dalej at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30582
[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dalej at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-02-02 21:00:35 |2005-03-25 00:01:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19225
[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Additional Comments From dalej at gcc dot gnu dot org 2005-03-30 20:27 --- Fixed (4.1 only) -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19225
[Bug middle-end/19225] [3.4 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Additional Comments From dalej at gcc dot gnu dot org 2005-04-06 21:02 --- Also fixed in 4.0 and 3.4 branches. Closing. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19225
[Bug tree-optimization/20803] New: Pseudo-infinite recursion in ivopts
Compile the following with -O1 in 4.0 branch. Don't be in a hurry; I killed it
after 10 minutes, but I'm told it goes for hours.
With -fno-ivopts added it completes almost immediately. The recursion is
in instantiate_parameters_1 called from simple_iv.
/**/
extern int Loop1Max,Loop2Max;
void bar(int a, int b, int c);
void foo(int parm);
/**/
#define x7(x) x;x;x;x;x;x;x
#define REPL(x) x7(x);x7(x);x7(x);x7(x);x7(x);x7(x)
// 6 * 7 = 42 (0.06 seconds compile-time for GCC 3.3, 1 year for GCC
4.0)
// Changing REPL from 42 to 21 will reduce GCC 4.0 compile-time to 20
sec
onds.
/**/
void foo(int parm)
{
register int x,y;
register int a,b,c;
a = b = c = parm;
for (y=0; yhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=20803
[Bug tree-optimization/20803] Pseudo-infinite recursion in ivopts
-- What|Removed |Added CC||sebastian dot pop at cri dot ||ensmp dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20803
[Bug tree-optimization/20803] Pseudo-infinite recursion in ivopts
-- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20803
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From dalej at gcc dot gnu dot org 2005-09-21 17:23 --- I agree with Paolo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug middle-end/24263] [4.1 Regression] gcc.dg/torture/builtin-convert-1.c fails
--- Comment #11 from dalej at gcc dot gnu dot org 2005-10-10 15:47 --- Yes, I think it's true that (float)floor((double)f) == floorf(f). We could make that routine look for that case, although it wasn't before, and I think your test was passing by accident (i.e. the invalid tranformation that it actually was doing, happened to work.) I should be able to look at it later this week, have a firedrill at the moment. (On darwin convert_to_real does not get called with anything that looks like that, and all the builtin-convert tests pass. I'm not sure why Sparc is different.) -- dalej at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dalej at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24263
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
--- Comment #9 from dalej at gcc dot gnu dot org 2005-10-24 17:58 --- Another bug in renaming just showed up on darwin rs6000. When renaming changes a register in the RTL, it does not make the corresponding change in attached FRAME_RELATED notes. This leads to inaccurate Dwarf exception tables and runtime failures in unwinding after a throw. Don't know how widespread this would be; other rs6000 targets for sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Comment #7 from dalej at gcc dot gnu dot org 2005-10-24 18:55 --- Indeed, the failing case I saw was C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug rtl-optimization/23392] [4.1 Regression] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Comment #8 from dalej at gcc dot gnu dot org 2005-10-24 21:41 --- Incidentally, this bug started getting tickled (more, at least) on darwin due to the fix for 15813. I'm not aware of any problems before that. However, the 15813 fix is correct and necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug rtl-optimization/19398] secondary reloads don't consider "m" alternatives
--- Additional Comments From dalej at gcc dot gnu dot org 2005-08-01 18:46 --- This is very close to the problem I ran into reported here: http://gcc.gnu.org/ml/gcc/2005-07/msg01084.html That one is fixed by the combination of the patch in PR 19653 and the patch here: http://gcc.gnu.org/ml/gcc/2005-07/msg01123.html However that is insufficient to fix this case. The difficulty is that regmove causes the same pseudo to be used for the operands and the result of the multiply. Consider that reg as all one, ST(0) is the best place for it, and you get the extra move. If you turn off regmove, the patches above fix this problem. Maybe we should do that? It seems like the register allocator should be doing what regmove is trying to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19398
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From dalej at gcc dot gnu dot org 2005-08-01 20:56 --- Unfortunately the latest version of this patch causes a bootstrap failure on ppc: ../../gcc3.apple.200502/gcc/reload.c: In function 'find_reloads': ../../gcc3.apple.200502/gcc/reload.c:4512: internal compiler error: in do_output_ reload, at reload1.c:6936 which is /* If is a JUMP_INSN, we can't support output reloads yet. */ gcc_assert (!JUMP_P (insn)); Digging further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug target/19653] x87 reg allocated for constants for -mfpmath=sse
--- Additional Comments From dalej at gcc dot gnu dot org 2005-08-02 22:57 --- Preceding patch fixes the ICE I was getting. The tests following the modified area in find_reloads were being skipped in cases where they weren't before (in particular, when output reloads are not allowed, this was not detected). The revised patch moves the area Paolo modified below those tests. Going through more testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
[Bug tree-optimization/21293] New: ICE on valid
The following crashes at compile time with -O2, on a local compiler built from
4.0 branch sources:
foo3.c: In function 'gciprt_':
foo3.c:8: internal compiler error: in set_value_handle, at tree-vn.c:179
(This has been cut down from a large original which did not have all those
uninitialized variables.)
struct {
int k_;
} detwfn_;
struct {
double x_[1];
} fmcom_;
void gciprt_(int *iw_)
{
int Tmp8, ibcon_, iwrk_, ibo_, jstsym_, lcivec_, iacon_, igmul_;
int i_, nsym_, ipica_, ipicb_;
ibo_ = iwrk_ + 43;
Tmp8 = detwfn_.k_;
for(i_ = 1;i_ <= Tmp8;i_++) {
gcisym_(iw_,&fmcom_.x_[lcivec_ + -1],&fmcom_.x_[ipica_ +
-1],&fmcom_.x_[ipicb_ + -1],
&fmcom_.x_[iacon_ + -1],&fmcom_.x_[ibcon_ + -1],&fmcom_.x_[igmul_ +
-1],&nsym_,
&fmcom_.x_[iwrk_ + -1],&fmcom_.x_[ibo_ + -1],&jstsym_);
}
return ;
}
--
Summary: ICE on valid
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.0.0
GCC host triplet: powerpc-apple-darwin8.0.0
GCC target triplet: powerpc-apple-darwin8.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
[Bug tree-optimization/21293] [4.0 Regression] ICE in set_value_handle
--- Additional Comments From dalej at gcc dot gnu dot org 2005-04-30 01:56 --- Yes, I figured out that allowing overflowed constants in is_gimple_min_invariant would fix it. But that doesn't seem like it should be necessary for correctness. Zdenek changed it to improve optimization, not because it broke things. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
[Bug tree-optimization/21293] [4.0 Regression] ICE in set_value_handle
--- Additional Comments From dalej at gcc dot gnu dot org 2005-04-30 02:45 --- Certainly. Presumably the expectation was that overflowed constants would not get here. But I confess I don't see why not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
[Bug tree-optimization/21562] New: Quiet bad codegen (unrolling + tail call interaction)
Compile the following with -O2 -funroll-loops and you get bad codegen. An
uninitilaized value
is used as "pos" in computing the store address for mr[pos]=1 at the top of the
function. The
first dump where it's wrong seems to be "nrv". If you unroll by hand it comes
out correct.
extern int delta[8];
extern unsigned char board[421];
void
ping_recurse(int pos, int mr[400], int color)
{
int k;
mr[pos] = 1;
for (k = 0; k < 4; k++) {
int apos = pos + delta[k];
if (mr[apos] == 1 || board[apos] == color)
ping_recurse(apos, mr, color);
}
}
Beginning of codegen on darwin8:
_ping_recurse:
mflr r0
bcl 20,31,"L001$pb"
"L001$pb":
stmw r28,-16(r1)
mr r29,r4
mflr r31
mr r28,r5
stw r0,8(r1)
stwu r1,-80(r1)
L25:
addis r11,r31,ha16(L_delta$non_lazy_ptr-"L001$pb")
slwi r2,r30,2 <<<< R30 uninitiailized
--
Summary: Quiet bad codegen (unrolling + tail call interaction)
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dalej at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin8.0.0
GCC host triplet: powerpc-apple-darwin8.0.0
GCC target triplet: powerpc-apple-darwin8.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21562
[Bug tree-optimization/21562] [4.0/4.1 Regression] Quiet bad codegen (unrolling + tail call interaction)
--- Additional Comments From dalej at gcc dot gnu dot org 2005-05-16 21:44 --- OK, what happens is that tail call creates a block 0 with multiple predecessors, and the out-of-ssa pass mangles that into this form: # BLOCK 0 # PRED: 9 [14.9%] (true,exec) 1 [29.0%] (true,exec) :; posD.1132 = aposD.1138; # SUCC: 12 [100.0%] (fallthru) # BLOCK 12 # PRED: 0 [100.0%] (fallthru) ENTRY [100.0%] (fallthru,exec) :; *((intD.0 *) ((unsigned intD.3) posD.1132 * 4) + mrD.1133) = 1; where ENTRY no longer falls into block 0, but is expected to jump to block 12. Expand has no idea such a thing is possible and falls through anyway. While it's not obvious in 4.0 branch, the addition of a verify_flow_info failure in mainline makes it apparent this is not supposed to happen. One way to fix this is change tailcall so it splits block 0 instead of creating multiple predecessors for it. I'll go do that unless somebody has a better idea. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dalej at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21562
