GCC 4.7.0 as a AVR cross compiler
Hi, I am not sure this is the right place to ask this, but how do I get gcc 4.7.0 to compile as a cross compiler for the Atmel AVR series? The native host is an x86 IA32 box running Slackware, gcc 3.3.6. I have successfully compiled and installed (in /usr/local/avr) binutils 2.22 and set my path to include the newly compiled binutils (/usr/local/avr/bin). I can not seem to get gcc 4.7.0 to compile; it will not complete the configuration stage complaining about missing packages (GMP, MPFR and MPC). I have tried to cross compile these packages for the Atmel AVR Mega series but the only one that seems to complete is the GMP package. The cross compile did produce a lib file (and install it and the gpm.h file in the correct place) but nothing else would accept that GMP was present on the system. I would like to ask the maintainer or tester of the AVR code to include some notes on cross compiling GCC in future. Any advice on how to get gcc installed as a cross compiler would be most welcome. TIA, -- Stuart Microsoft - products from convicted criminals
Re: [RFA] Invalid mmap(2) assumption in pch (ggc-common.c)
On Apr 23, 2005, at 5:42 PM, Matt Thomas wrote: Running the libstdc++ testsuite on NetBSD/sparc or NetBSD/sparc64 results in most tests failing like: :1: fatal error: had to relocate PCH compilation terminated. compiler exited with status 1 This is due to a misassumption in ggc-common.c:654 (mmap_gt_pch_use_address): This version assumes that the kernel honors the START operand of mmap even without MAP_FIXED if START through START+SIZE are not currently mapped with something. That is not true for NetBSD. Due to MMU idiosyncracies, some architecures (like sparc and sparc64) will align mmap requests that don't have MAP_FIXED set for architecture specific reasons). Is there a reason why MAP_FIXED isn't used even though it probably should be? I can't speak directly to your question, but you might try the version in config/host-darwin.[ch]. This implementation statically allocates a 1G array in the bss, unmaps it, and maps the PCH there. As the commentary indicates, it looks kludgy, but it does seem to make PCH more reliable. I'm not absolutely clear on the details anymore, but I think you need host-darwin.c in your link, and host-darwin.h must be #included wherever you initialize your host langhooks. (You could also try MAP_FIXED yourself; that's certainly easier than my suggestion above. :-) stuart hastings Apple Computer
pr11135: make PIC register a pseudo
Regarding http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11135 How much effort would it take to fix this, at least for x86 (32-bit)? stuart hastings Apple Computer
Updating @gcc.gnu.org email forwarding
Hi, I'm looking to update the forwarding address for my @gcc.gnu.org email address, but appear to have lost (if I ever had) my private key. Could someone point me in the right direction for fixing this? Thanks, Stu
RE: GCC 4.7 Status Report for *-rtems
> bfin - REGRESSION - ICE - >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51003 This looks like a known, general issue which Bernd had a fix for, but it doesn't appear to have been checked in yet: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01524.html Stu
ICE building compiler
Hi,
I'm investigating an ICE building the Blackfin compiler from trunk.
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:
In function ‘eoshift1’:
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
error: unable to find a register to spill in class ‘CCREGS’
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
error: this is the insn:
(insn 546 540 479 46 (set (reg:BI 455)
(le:BI (reg/v:SI 6 R6 [orig:122 size ] [122])
(const_int 0 [0])))
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:212
119 {compare_le}
(nil))
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
internal compiler error: in spill_failure, at reload1.c:2123
The problem occurs when the ce2 pass does an IF-CASE-2 transformation, moving
an instruction which sets the condition code register into a block between
another instruction which sets the condition code register and its conditional
jump.
e.g.
block 44:
set cc = x;
if cc jump;
...
block 49:
set cc = y;
block 51:
if cc jump;
gets transformed into...
block 44:
set cc = x;
set cc = y;
if cc jump;
...
block 51:
if cc jump;
When we reach cc=y in the reload pass the CC reg is already in use from cc=x,
find_reg fails to find an alternative and we bomb out.
This seems like something IF-CASE-2 could do a lot, so is it supposed to avoid
such scenarios? or should reload handle the situation by finding the previous
use of CC and spilling it to memory?
Any pointers would be appreciated.
Thanks,
Stu
RE: ICE building compiler
Hi, Whilst investigating an ICE with the Blackfin compiler, I bumped in to a bit of code which seems questionable: in reload1.c:reload() we call select_reload_regs() and then check if failure was set. However, looking at find_reload_regs() (called via select_reload_regs()), the only time we set failure is immediately after a call to spill_failure() which doesn't return. Is spill_failure the correct function to be using here? It seems like the intention of the code was to note the spill_failure and then try and then try and fix it by jumping to the "failed:" label. Cheers, Stu
RE: ICE building compiler
>Whilst investigating an ICE with the Blackfin compiler, I bumped in to a >bit of code which seems questionable: > >in reload1.c:reload() we call select_reload_regs() and then check if >failure was set. However, looking at find_reload_regs() (called via >select_reload_regs()), the only time we set failure is immediately after >a call to spill_failure() which doesn't return. Is spill_failure the >correct function to be using here? It seems like the intention of the >code was to note the spill_failure and then try and fix it >by jumping to the "failed:" label. any feedback on this? Thanks, Stu
spill failure after IF-CASE-2 transformation
Hi,
I'm investigating the following ICE building the Blackfin compiler from trunk:
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:
In function ÃâËeoshift1Ãââ:
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
error: unable to find a register to spill in class ÃâËCCREGSÃââ
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
error: this is the insn:
(insn 546 540 479 46 (set (reg:BI 455)
(le:BI (reg/v:SI 6 R6 [orig:122 size ] [122])
(const_int 0 [0])))
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:212
119 {compare_le}
(nil))
/home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:250:1:
internal compiler error: in spill_failure, at reload1.c:2123
The problem occurs when the ce2 pass does an IF-CASE-2 transformation, moving
an instruction which sets the condition code register into a block between
another instruction which sets the condition code register and its conditional
jump.
e.g.
block 44:
set cc = x;
if cc jump;
...
block 49:
set cc = y;
block 51:
if cc jump;
gets transformed into...
block 44:
set cc = x;
set cc = y;
if cc jump;
...
block 51:
if cc jump;
When we reach cc=y in
reload1.c:reload()->select_reload_regs()->find_reload_regs(), find_reg() fails
and we call spill_failure(), which doesn't return. However, right after the
call to spill_failure, we set the failure flag, which is checked for right
after select_reload_regs returns. I'm a little confused as to what the
intention of this code was. It seems like the idea was to note the
spill_failure and then try and fix it by jumping to the "failed:" label, but
obviously this never happens due to the call to spill_failure. A spill failure
like this looks very fixable and I would expect the previously live register
(cc=x) to be spilled. Is there a reason this isn't attempted here?
Thanks,
Stu
strict aliasing issue
Here's my reduced testcase:
typedef long GLint;
extern void aglChoosePixelFormat(const GLint *);
void find(const int *alistp) {
const int *blist;
int list[32];
if (alistp)
blist = alistp;
else {
list[3] = 42; /* this store disappears with -O1 -fstrict-
aliasing */
blist = list;
}
aglChoosePixelFormat((GLint*)blist);
}
(The original testcase is C++, from the FLTK project.)
If I compile this with -O1 -fstrict-aliasing, the "= 42" store
disappears. I've confirmed this on mainline PPC and x86.
I'm not a language lawyer; is this a legal program? (If the program
is legal, should I file a PR?)
stuart hastings
Apple Computer
RE: spill failure after IF-CASE-2 transformation
>spill_failure does return for asms since we don't want to ICE on bad
>user code. That's all that's going on here.
ahh, thanks.
>It sounds like ifcvt needs to be fixed. Your example:
>> block 44:
>> set cc = x;
>> set cc = y; (*)
>> if cc jump;
>
>looks like an invalid transformation, but I suspect rather than setting
>the CC register, the (*) insn is setting a pseudo (more accurate RTL
>would be useful). There are some cases in ifcvt.c which check
>targetm.small_register_classes_for_mode already, this is probably what
>should be done to prevent this transformation.
You suspect correctly, cc=x sets CC whereas cc=y is a pseudo which can only
match CC.
Presumably I must check all instructions in the else_bb for modifications to
small_register_classes_for_mode_p? e.g. see below.
Does this seem reasonable?
Thanks,
Stu
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 8d81c89..b605a63 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -3924,6 +3924,7 @@ find_if_case_2 (basic_block test_bb, edge then_edge, edge
else_edge)
basic_block else_bb = else_edge->dest;
edge else_succ;
int then_prob, else_prob;
+ rtx insn;
/* If we are partitioning hot/cold basic blocks, we don't want to
mess up unconditional or indirect jumps that cross between hot
@@ -3957,6 +3958,25 @@ find_if_case_2 (basic_block test_bb, edge then_edge,
edge else_edge)
/* ELSE has one predecessor. */
if (!single_pred_p (else_bb))
return FALSE;
+
+ /* Avoid small_register_classes_for_mode_p dests. */
+ FOR_BB_INSNS (else_bb, insn)
+{
+ rtx set, dest;
+
+ if (!NONDEBUG_INSN_P (insn) || JUMP_P (insn))
+continue;
+ set = single_set (insn);
+ if (!set)
+return FALSE;
+
+ dest = SET_DEST (set);
+ if (!REG_P (dest))
+continue;
+ if (targetm.small_register_classes_for_mode_p (GET_MODE (dest)))
+return FALSE;
+}
/* THEN is not EXIT. */
if (then_bb->index < NUM_FIXED_BLOCKS)
RE: spill failure after IF-CASE-2 transformation
Ping. >>looks like an invalid transformation, but I suspect rather than setting >>the CC register, the (*) insn is setting a pseudo (more accurate RTL >>would be useful). There are some cases in ifcvt.c which check >>targetm.small_register_classes_for_mode already, this is probably what >>should be done to prevent this transformation. > >You suspect correctly, cc=x sets CC whereas cc=y is a pseudo which can >only match CC. > >Presumably I must check all instructions in the else_bb for >modifications to small_register_classes_for_mode_p? e.g. see below. > >Does this seem reasonable? Patch here: http://gcc.gnu.org/ml/gcc/2012-02/msg00296.html Thanks, Stu
RE: spill failure after IF-CASE-2 transformation
>Not really. I think in dead_or_predicable you need to check in the > /* Try the NCE path if the CE path did not result in any changes. */ >block (I assume this is where we end up in this testcase) that none of >the live hard regs at the point where we are going to insert the insns >are in small register classes. small_register_classes_for_mode_p is >unfortunately not a good interface to answer that question. > >It looks like noce_get_condition probably didn't find the instruction >setting CC? Maybe you can paper over the problem for the moment by >making sure it does. The problem with noce_get_condition is that if the condition variable is a MODE_INT register it will return it and set earliest as the jump insn itself. I'm not sure why this is the case, but it seems like something we don't want to be doing in this situation. Is there a reasonable check that should be made to avoid noce_get_condition doing this? e.g. if the condition var is a reg and !small_register_classes_for_mode_p. Thanks, Stu
RE: spill failure after IF-CASE-2 transformation
>Make an exception for BImode and small_register_classes_for_mode_p
>(BImode).
Thanks Bernd.
Would this be acceptable:
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 8d81c89..e4e13ab 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2295,7 +2295,9 @@ noce_get_condition (rtx jump, rtx *earliest, bool
then_else_reversed)
cond = XEXP (SET_SRC (set), 0);
tmp = XEXP (cond, 0);
- if (REG_P (tmp) && GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT)
+ if (REG_P (tmp) && GET_MODE_CLASS (GET_MODE (tmp)) == MODE_INT
+ && (GET_MODE (tmp) != BImode
+ || !targetm.small_register_classes_for_mode_p (BImode)))
{
*earliest = jump;
