Denis Vlasenko wrote:
The following macro expands to some rather frightful code on the AVR:
#define BSWAP_16(x) \
x) >> 8) & 0xff) | (((x) & 0xff) << 8))
Sometimes gcc is generating better code if you cast
values instead of masking. Try:
( (uint8_t)((x) >> 8) | ((uint8_t)(x))
On Nov 6, 2006, at 7:49 PM, Andrew Pinski wrote:
Right now after patches by the Apple folks causes you to need a
newer dwarfutils
I think that is a bug, and that bug has now been fixed. Let me know
if there is any other badness I missed (or introduced along the way).
Right now on the Powe
Brendon Costa <[EMAIL PROTECTED]> writes:
| Hi all,
|
| I have just come across a small difference in the way the C an C++
| front ends handle anonymous struct types which is causing me some
| grief. In particular the following code:
|
| typedef struct
| {
| int b1;
| int b2;
| } Blah;
|
[EMAIL PROTECTED] wrote:
> Does the LTO branch try to achieve that the complete information for a
> "Program"
> can be sufficiently stored (in a file)? If this is already there, could anyone
> provide some pointers to the API?
Yes, on the LTO branch, we are working to store the entire translatio
On Saturday 18 November 2006 00:30, Shaun Jackman wrote:
> The following macro expands to some rather frightful code on the AVR:
>
> #define BSWAP_16(x) \
> x) >> 8) & 0xff) | (((x) & 0xff) << 8))
Sometimes gcc is generating better code if you cast
values instead of masking. Try:
On Mon, 2006-11-27 at 12:02 +1100, Brendon Costa wrote:
> And apply the TYPE_MAIN_VARIANT on "Another", C++ returns Blah and C
> again returns the anonymous RECORD_TYPE. In my situation this is causing
> some grief as i need a consistent name for the main varient type across
> translation units.
Hi all,
I have just come across a small difference in the way the C an C++ front
ends handle anonymous struct types which is causing me some grief. In
particular the following code:
typedef struct
{
int b1;
int b2;
} Blah;
void Function(Blah* b) {}
When i get the Blah type in the func
> I am considering implementing the following feature into GCC using
> the patch on http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html
> : a compiler probe which permits to probe the run of a compilation,
> e.g. by displaying in emacs or a graphical GTK application the
> current pass, Gimple r
On Nov 26, 2006, at 3:20 PM, Basile STARYNKEVITCH wrote:
The textual protcol should permit to examine, but not change, the
compilation state.
Sounds like a bad idea. I agree with the debugger comment. You're
free to start up the compilation process with ptrace from your GUI
and query/dis
I'm having a problem where choose_reload_regs() calls
subreg_regno_offset() with invalid parameters for my 16-bit ix86 port. It
starts out fine in emit_reload_insns():
Breakpoint 6, emit_reload_insns (chain=0x882b5a8) at reload1.c:7506
reg_last_reload_reg[nregno] = rld[r].reg_rt
> when given the -fcompiler-probe flag, it should get an a string
> option with it. If this string is a (Unix) file path it indicate a
> Unix socket or FIFO; if it starts with a vertical pipe bar | it
> starts the command and communicate with it thru pipes. Typically the
> command is some
Dear All,
I am considering implementing the following feature into GCC using the
patch on http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html : a
compiler probe which permits to probe the run of a compilation,
e.g. by displaying in emacs or a graphical GTK application the current
pass, Gimple
On Wed, 22 Nov 2006, Vincent Lefevre wrote:
> Hi,
>
> I'm posting this announce to this list as GCC now uses MPFR...
>
> The release of MPFR 2.2.1 is imminent. Please help to make this
> release as good as possible by downloading and testing this
> release candidate:
>
> Changes from version 2.2.0
Hi there
i'm looking for a way to emit (dump) complete global and local symbol table
entries for any given (C) program. For now, it would be satisfactory if this
was properly handled for single-source-file programs. But what i would like to
do basically is to store the entire information that woul
On Sat, Nov 25, 2006 at 09:36:00PM -0500, Daniel Jacobowitz wrote:
> It never returns from ppc64_elf_gc_mark_hook (spins looking things up
> in a hash table, I don't have the matching source handy). I expect
> this is fixed in later binutils
2006-01-17
> Is there some way we can avoid an infinit
15 matches
Mail list logo
