Hello All
I just merged the trunk (svn rev 187397) into the MELT branch (svn 187401)
and I of course noticed the merging of gimple_seq into gimple (dated
2012-05-03).
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00068.html
However, the type gimple_seq still appears in a lot of source files
(mo
Hi,
On Fri, 11 May 2012, Basile Starynkevitch wrote:
> However, the type gimple_seq still appears in a lot of source files
> (mostly gcc/gimple*.c & gcc/tree*.c)
>
> Is this intended, or is this a temporary situation, and
> further patches would remove all occurrences of gimple_seq everywhere?
On Fri, May 11, 2012 at 02:12:32PM +0200, Michael Matz wrote:
> On Fri, 11 May 2012, Basile Starynkevitch wrote:
>
> > However, the type gimple_seq still appears in a lot of source files
> > (mostly gcc/gimple*.c & gcc/tree*.c)
> >
> > Is this intended, or is this a temporary situation, and
>
Hi,
MULTILIB_OPTIONS containing options defined in DRIVER_SELF_SPEC seemed
to be fine in GCC46 but fail in GCC47.
For example, I have:
xap.h:
#define DRIVER_SELF_SPECS \
"%{help:-v} %"%{mno-args-span-regs-and-mem:-mno-split-args}
%"%{mno-inline-block-copy-mod
On 05/09/12 17:15, DJ Delorie wrote:
> A TPF stack frame has up to two return addresses in it. The second
> one is used when the call crosses a shared object domain, where a stub
> is between the two functions. The stub does not change the stack, but
> it does eventually chain to the "correct" re
> Can any of these stubs throw exceptions? What are they used for?
I suspect they're simple thunks. I can ask what they do.
> My first reaction is to simply consider them invisible system frames
> and ignore them when it comes to unwinding...
That's what we're trying to do, but the CFA corres
On 05/11/12 08:45, DJ Delorie wrote:
> That's what we're trying to do, but the CFA corresponds to the
> "normal" cfa but with a different (wrong) return address. The
> fallback handler corrects the RA and the next iteration sees the
> corrected frame.
I think some ascii art or a pointer to a manu
On 05/11/12 08:45, DJ Delorie wrote:
> If the fallback handler borks the cfa by, for example, just
> subtracting 1 from it, will that confuse the unwinder? Or will it
> "just work".
FYI this isn't entirely dis-similar to the solution we're currently
using for mips16 stubs. See CALL_STUB_RET in l
> I'm a bit confused as to how the fallback handler can find the correct
> RA but the "normal" unwind path can't.
The fallback knows what address range corresponds to the stubs. It's
"magic".
> How do all these things fit on the stack?
Every stack frame has room for two return addresses.
The
Snapshot gcc-4.6-20120511 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120511/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I'm working on a DSP port whose unit reservations are very sensitive to
operand signature. E.g., for an assembler mnemonic, there can be 35-50
different combinations of operand register classes, each having different
impacts on latencies and function units. For assembler code generation, very
few
I am trying to build GCC 4.7.0 on OS X.
I have compiled and installed (via make install) GMP, MPFR, MPC and PPL 0.11.
However when I am trying to build CLOOG-PPL 0.15.11 it fails to build.
During ./configure it says:
checking for location of PolyLib... installed in standard location
check
On 05/11/12 16:00, Greg McGary wrote:
> My question is this: does it make sense to double MAX_RECOG_ALTERNATIVES so
> that I can use insn attributes to identify operand signatures, or should I use
> another approach?
After some exploration, I don't see that another approach is even possible. The
13 matches
Mail list logo
