unless x is an integer larger than 1/2 UINT_MAX... then it's still a bad test.
it's safer to test if the signed is less than 0 otherwise cast that to
unsigned.
On Sun, Sep 26, 2010 at 10:06 PM, foxmuldrs...@yahoo.com
wrote:
> Use the explicit override if you need signed comparison.
>
> unsigned
On 27/09/2010 07:51, J Decker wrote:
The standards did not leave this open. They define precisely what is
supposed to happen.
Really? I'll have to drop this whole lobbying effort then. That
makes me sad that they didn't define it to be comparing of the numbers
where there are overlaps in si
Hello Luke,
Luke A. Guest wrote:
> I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM.
Thanks :-)
> Any pointers would be gratefully received. I'm fairly sure I know where
> to start.
A few general points, jic.
The first thing will be to adjust your target system.ads to
On Mon, 2010-09-27 at 11:12 +0200, Olivier Hainque wrote:
> Hello Luke,
>
> Luke A. Guest wrote:
> > I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM.
>
> Thanks :-)
Well, I'm reading as much as I can regarding this, but finding it hard
to work some things out. I've been re
On Sun, Sep 26, 2010 at 4:01 AM, Ian Lance Taylor wrote:
> Jonathan Wakely writes:
>
>> Thank you, Frédéric, despite a few bug reports the upgrade went very
>> smoothly and it's great that we have a modern version of Bugzilla now.
>>
>> Was it a conscious decision for the "Add me to CC list" chec
Hi,
This is regarding to the alignment error generated by GDB when compiled
in
same GCC with u-boot makefile.
I wrote a small code consisting of following statements for the ARM
platform
int* pInt = (int*)0x10002004; //word-aligned
char* pChar = (char* )0x10003005; //non-wor
Hi Thomas,
[Note: You sent this to g...@sourceware.org but the correct address to
use is g...@gcc.gnu.org].
int* pInt = (int*)0x10002004; //word-aligned
char* pChar = (char* )0x10003005; //non-word-aligned
*pInt = 0x34;
*pChar = 'A';
The assembly mnemonic
Luke A. Guest wrote:
> Well, I'm reading as much as I can regarding this, but finding it hard
> to work some things out.
That's a pretty complex and very precise machinery overall.
> I've been reading through:
> http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html and trying some example
> code in C+
On 09/27/2010 01:23 AM, Jay K wrote:
>
> Hi. You know, gmp/mpfr/mpc are a significant
> portion of building any frontend/backend.
I disagree. Most of the time I don't notice them.
> The result is a lot faster to build, if you are just doing a just
> a single stage build of a compiler.
Sure, bu
On 09/27/2010 10:36 AM, Luke A. Guest wrote:
> On Mon, 2010-09-27 at 11:12 +0200, Olivier Hainque wrote:
>> Hello Luke,
>>
>> Luke A. Guest wrote:
>>> I'm having a look into getting DWARF2 exceptions (ZCX) working on ARM.
>>
>> Thanks :-)
>
> Well, I'm reading as much as I can regarding this, but
On Mon, 2010-09-27 at 12:33 +0200, Olivier Hainque wrote:
> Luke A. Guest wrote:
> > Well, I'm reading as much as I can regarding this, but finding it
hard
> > to work some things out.
>
> That's a pretty complex and very precise machinery overall.
You're not wrong.
> > I've been reading throug
On 27 September 2010 05:19, J Decker wrote:
>
> I don't know why standards left this open, other than there isn't a
> single-instruction translation from code to CPU for the comparison;
>
> But if it's not fixed, this warning should definatly be issued at
> default warning level. This should be m
Wow that is fast.
My fastest machine, and I have several slower:
gmp
time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared
-enable-static && make && ssh r...@localhost \"cd `pwd` && make install\""
real 2m2.594s
mpfr
time sh -c "./configure -disable-shared -enable-static && ma
On Mon, Sep 27, 2010 at 1:39 PM, Jay K wrote:
>
> Wow that is fast.
>
>
> My fastest machine, and I have several slower:
>
>
> gmp
> time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared
> -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\""
> real 2m2.594s
>
A while back I posted a question about adding edit-and-continue
abilities. Since then I've begun work on a rapid development compiler
(rdc) which has these abilities, but I've had some thoughts I'd like to
share, and receive some feedback from the GCC experts:
What if a subset of GCC could be use
[resending a reply sent to a private copy]
From: Olivier Hainque
To: "Luke A. Guest"
Subject: Re: Porting ZCX (not SJLJ) for GNAT ARM EABI
Date: Mon, 27 Sep 2010 15:18:59 +0200
Luke A. Guest wrote:
> > A quick glance suggests that your arm-linux port might be using the
> > latter (from t-linu
On Mon, Sep 27, 2010 at 07:47:48AM -0500, Rick C. Hodgin wrote:
> A while back I posted a question about adding edit-and-continue
> abilities.
Are you sure that is feasible? I mean, in principle, a caching
incremental compiler is probably feasible, but I cannot figure how you
could edit the sour
> A while back I posted a question about adding edit-and-continue
> abilities. Since then I've begun work on a rapid development compiler
> (rdc) which has these abilities, but I've had some thoughts I'd like to
> share, and receive some feedback from the GCC experts:
>
> What if a subset of GCC
> Most of the interesting bits happen in the linker+debugger...
Agreed, which is why the compiler side doesn't matter much in terms of
how much it does, just so long as it is correct and compliant. This is
the hard part I'm finding, which is why I'm looking to the GCC community
which spends a gre
On Mon, 27 Sep 2010 09:57:24 -0500
> If you haven't used this feature in Microsoft's Visual Studio, you can
> download Microsoft Visual Studio Express for free and see it in action.
[off-topic]
Well, I would imagine that Visual Studio Express runs only on Microsoft
Windows. Unfortunately, I don't
On 09/27/2010 03:47 AM, Luke A. Guest wrote:
> I can't see any mention of unwind in the the t-linux-eabi file, I'm
> probably missing something I just don't unerstand here :D
Because it's in config/arm/t-bpabi.
Do be clear on whether you're working on arm-linux-eabi, i.e. with
the ARM EABI unwind
On Thu, Apr 29, 2010 at 4:07 PM, Steven Bosscher wrote:
> 2010/4/30 Jan Hubicka :
>> Yep, I read that page (and saw some of implementation too). Just was not
>> able
>> to follow the precise feature set of LIPO (i.e. if it gets better SPEC
>> results
>> than LTO+FDO then why)
>
> OK, that's an
On Fri, Apr 30, 2010 at 12:07 PM, Xinliang David Li wrote:
>
> On Fri, Apr 30, 2010 at 11:12 AM, Jan Hubicka wrote:
> >> >
> >> > Interesting. My plan for profiling with LTO is to ultimately make it
> >> > linktime
> >> > transform. This will be more difficult with WHOPR (i.e. instrumenting
>
In this example, why isn't insn 117 scheduled before insn 115 ? What
is the dependency? The only thing they have in common is CC, but both
generate a value which is never used.
;; ==
;; -- basic block 15 from 114 to 118 -- after reload
;;
On Mon, Sep 27, 2010 at 11:04:10AM -0700, Neil Vachharajani wrote:
> On Thu, Apr 29, 2...@4:07 PM, Steven Bosscher wrote:
> > 2010/4/30 Jan Hubicka :
> >> Yep, I read that page (and saw some of implementation too). Just was not
> >> able
> >> to follow the precise feature set of LIPO (i.e. if it
DJ Delorie writes:
> In this example, why isn't insn 117 scheduled before insn 115 ? What
> is the dependency? The only thing they have in common is CC, but both
> generate a value which is never used.
I don't see anything in sched-deps.c which prevents using a register for
scheduling dependen
On 09/27/2010 01:30 PM, DJ Delorie wrote:
> (insn 115 114 117 15 dj.c:256 (parallel [
> (set (reg:SI 12 r12 [139])
> (plus:SI (reg:SI 3 r3 [orig:54 pretmp.923 ] [54])
> (reg:SI 12 r12 [138])))
> (set (reg:CC_ZSC 16 cc)
> (c
> I think it's probably a mistake to have the default ADD
> instruction SET the flags, rather than CLOBBER them.
How else would we optimize away compares?
On 09/27/2010 03:37 PM, DJ Delorie wrote:
>> I think it's probably a mistake to have the default ADD
>> instruction SET the flags, rather than CLOBBER them.
>
> How else would we optimize away compares?
By having a separate ADD that looks like your current one.
Combine will put them together for
Would we have to do that for *all* the math/logic ops, or just add?
On 09/27/2010 04:21 PM, DJ Delorie wrote:
> Would we have to do that for *all* the math/logic ops, or just add?
All of them of course.
r~
> That said, I suppose it wouldn't hurt to modify sched-deps
> to treat a SET+REG_UNUSED as a CLOBBER.
Early in sched_analyze_reg, check for ref==USE and a REG_UNUSED note,
and change ref to CLOBBER? I tried it, it didn't seem to help...
Index: sched-deps.c
=
On 27/09/2010 12:39, Jay K wrote:
> gmp
> time sh -c "CC=gcc-4.2 ./configure none-none-none -disable-shared
> -enable-static && make && ssh r...@localhost \"cd `pwd` && make install\""
> real2m2.594s
>
> mpfr
> time sh -c "./configure -disable-shared -enable-static && make && ssh
> r...@loc
The 64-bit PEI format has a SECREL32 relocation type. It
does not, however, have a SECREL64 relocation type. Which
means that for
> #define DWARF_REF_SIZE \
> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
we don't really have something to use for for dwarf2.
I could fake it wi
I only do one language, no driver, one stage, no libraries (none of libgcc,
libstdc++, libjava, libada, etc.), no fixincludes (the headers are probably
fine, and aren't used by this frontend anyway), the bootstrap compiler is
always pretty decent, thus one stage (or I'll "cheat" and do one full
On 28/09/2010 01:29, Richard Henderson wrote:
> The 64-bit PEI format has a SECREL32 relocation type. It
> does not, however, have a SECREL64 relocation type. Which
> means that for
>
>> #define DWARF_REF_SIZE \
>> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
>
> we don't real
On 28/09/2010 02:01, Jay K wrote:
> I only do one language, no driver, one stage, no libraries (none of libgcc,
> libstdc++, libjava, libada, etc.), no fixincludes (the headers are probably
> fine, and aren't used by this frontend anyway), the bootstrap compiler is
> always pretty decent, thus one
> Well, the other thing is: why not just build them once and install them to
> your $prefix? There's no need to build them in-tree every time if you have
> sufficiently up-to-date versions installed.
>
> cheers,
> DaveK
I have a CVS tree, used by others, that builds a frontend.
"Others" are
2010/9/28 Richard Henderson :
> The 64-bit PEI format has a SECREL32 relocation type. It
> does not, however, have a SECREL64 relocation type. Which
> means that for
>
>> #define DWARF_REF_SIZE \
>> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
>
> we don't really have something
2010/9/28 Kai Tietz :
> 2010/9/28 Richard Henderson :
>> The 64-bit PEI format has a SECREL32 relocation type. It
>> does not, however, have a SECREL64 relocation type. Which
>> means that for
>>
>>> #define DWARF_REF_SIZE \
>>> (dwarf_version == 2 ? DWARF2_ADDR_SIZE : DWARF_OFFSET_SIZE)
>>
>>
40 matches
Mail list logo
