On Wed, Aug 17, 2005 at 12:53:14PM -0700, James E Wilson wrote:
> Alternatively, patches can be put into bugzilla bug reports. This will
> help make sure it won't get forgotten.
That's where we were headed, as mentioned at the end of a paragraph in
the email with the patch: "Once we're happy with
On Wed, Aug 17, 2005 at 11:07:42PM -0400, Kaveh R. Ghazi wrote:
> Yeah, BFD can only do that because it forces the %A %B specifiers be
> in the front.
No, it's worse than that. %A and %B can appear anywhere in the format
string, but consume their args first. eg.
_bfd_default_error_handler ("sec
> But in cases like BFD, the code just does some pre-processing and then
> calls vfprintf. So there is no always correct value to inherit. The
> correct value to inherit from is the one which the user will link
> against, and for that the closest we can come to the right answer is
> the --st
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
> I strongly feel that the "inherit" command should not change the
> behavior of the inherited format depending on the --std= flag passed
> to GCC at compile time of the user's code. This change isn't right
> for users, their variable argument output r
> For example,
>
> #pragma GCC format "bfd" "inherit printf; %A: asection; %B: bfd"
>
> Here the "inherit" could be simply "printf" for whatever is
> appropriate for the current compilation, or it could be a specific
> standard name.
I strongly feel that the "inherit" command should not c
> To make this kind of thing useful, I see two paths that we can follow.
> The first is to simply not try to implement all of printf in a special
> language. Most printf extensions are not nearly as complex as printf
> itself. In fact, most simply add a few additional % conversions, with
>
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
>
> > Can't we just use some inline function written in plain C to check the
> > arguments and execute it at compile time using constant folding etc.?
>
>
> Do we have a sane way to (partially) execute optim
Florian Weimer <[EMAIL PROTECTED]> wrote:
>> I haven't tried to flesh this out any further. I'd be curious to
>> hear how people react to it.
>
> Can't we just use some inline function written in plain C to check the
> arguments and execute it at compile time using constant folding etc.?
Do we
Avr-gcc has it's own list as well:
avr-gcc-list@nongnu.org
You can try there as well.
Krishna.
On Thu, 18 Aug 2005, Rikard S wrote:
# Where do I start?
# I guess there is only some few files that I need to write or edit,
# using files for similar MCU's as "templates".
#
# If I would like to imp
On Aug 17, 2005, at 3:09 PM, Rikard S wrote:
Where do I start?
I'd start by using cvs and checking out the source code from mainline
and then fire up emacs.
I guess there is only some few files that I need to write or edit,
using files for similar MCU's as "templates".
Yes...
If I would
Where do I start?
I guess there is only some few files that I need to write or edit,
using files for similar MCU's as "templates".
If I would like to implement new AVR targets, which files are involved?
Who knows, maby I can contribute :-)
/Best Regards Rikard Strömmer
* Ian Lance Taylor:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
>> If I understand your %A/%B example correctly, it would look like this:
>
> OK, I can see how that might work in a simple case. Now, can you give
> me an example of matching %d with the various flags? In particular,
> are you g
Florian Weimer <[EMAIL PROTECTED]> writes:
> If I understand your %A/%B example correctly, it would look like this:
OK, I can see how that might work in a simple case. Now, can you give
me an example of matching %d with the various flags? In particular,
are you going to write a loop, and is gcc
Erik Christiansen wrote:
> I've taken the liberty of cleaning up the L_callt_save_interrupt
> #ifdef, making it consistent with the following one for
> L_callt_save_all_interrupt. (This not only removes the .text error, but
> adopts the easier to handle layout of the latter.)
Patches should be sen
* Ian Lance Taylor:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>
>> * Ian Lance Taylor:
>>
>> > I haven't tried to flesh this out any further. I'd be curious to hear
>> > how people react to it.
>>
>> Can't we just use some inline function written in plain C to check the
>> arguments and exec
Torsten Mohr wrote:
> I wonder now how to proceed, do i need to report this stuff officially
> somewhere? I also got no answer to my mail from saturday morning,
> subject line "-mwarn-signed-overflow". I had to do that change to
> make gcc-3.4.4 compile.
gcc bugs can be reported into our bugzill
F. Heitkamp wrote:
> a particular cpu. Looking at the specs file for the host compiler the
> default is -mppc. When I gave the "--with-cpu=7400" shouldn't that have
> made the default -m7400?. What about xgcc, how can I make that use
> the 7400 cpu?
Perhaps this is a case that gcc doesn't hand
Balaji V. Iyer wrote:
> Pass this "live/not-live" flag to the register allocation process so that
> it can output instruction in such a way (please see example below) (I want
> this information to be passed into .md stage)
You can't get cycle-accurate life time info in the register allocator
unles
Florian Weimer <[EMAIL PROTECTED]> writes:
> * Ian Lance Taylor:
>
> > I haven't tried to flesh this out any further. I'd be curious to hear
> > how people react to it.
>
> Can't we just use some inline function written in plain C to check the
> arguments and execute it at compile time using co
On Aug 17, 2005, at 12:19 PM, Florian Weimer wrote:
Can't we just use some inline function written in plain C to check the
arguments and execute it at compile time using constant folding etc.?
I like this idea, but, I'm probably weird.
* Ian Lance Taylor:
> I haven't tried to flesh this out any further. I'd be curious to hear
> how people react to it.
Can't we just use some inline function written in plain C to check the
arguments and execute it at compile time using constant folding etc.?
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
[ Moved from gcc-patches to gcc ]
> At this point, I don't do any parsing of the "format-checking-data",
> this is where I would expect Ian's state machine language to appear.
To make this kind of thing useful, I see two paths that we can follow.
Th
Daniel Towner wrote:
> register renaming is able to change the registers used by the function
> from callee-save to caller-save, removing any need for the
> save/restore/stack adjust code in the prologue/epilogue. However, the
> instructions which perform these operations are still emitted.
I doub
On Aug 17, 2005, at 8:05 AM, Andrew Pinski wrote:
On Aug 17, 2005, at 11:01 AM, Marcel Moolenaar wrote:
On Aug 17, 2005, at 12:09 AM, Gerald Pfeifer wrote:
On Mon, 15 Aug 2005, Marcel Moolenaar wrote:
I see the same on ia64-hp-hpux11.23, hppa1.1-hp-hpux11.11 and
hppa64-
hp-hpux11.1
On Aug 17, 2005, at 11:01 AM, Marcel Moolenaar wrote:
On Aug 17, 2005, at 12:09 AM, Gerald Pfeifer wrote:
On Mon, 15 Aug 2005, Marcel Moolenaar wrote:
I see the same on ia64-hp-hpux11.23, hppa1.1-hp-hpux11.11 and hppa64-
hp-hpux11.11.
I haven't had time to analyze the problem, though.
Do
On Aug 17, 2005, at 12:09 AM, Gerald Pfeifer wrote:
On Mon, 15 Aug 2005, Marcel Moolenaar wrote:
I see the same on ia64-hp-hpux11.23, hppa1.1-hp-hpux11.11 and hppa64-
hp-hpux11.11.
I haven't had time to analyze the problem, though.
Does it work for you as well now?
I still have the failur
-Original Message-
From: [EMAIL PROTECTED] on behalf of F. Heitkamp
Sent: Wed 8/17/2005 8:05 AM
To: James E Wilson
Cc: gcc@gcc.gnu.org
Subject: Re: ppc assembler problem
On Tue, 16 Aug 2005, James E Wilson wrote:
> F. Heitkamp wrote:
>> ../../gcc-cvs-3-3/gcc//gcc/unwind-dw2.c -o libgc
On Tue, 16 Aug 2005, James E Wilson wrote:
F. Heitkamp wrote:
../../gcc-cvs-3-3/gcc//gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o
/tmp/ccNkOiHW.s: Assembler messages:
/tmp/ccNkOiHW.s:3142: Error: Unrecognized opcode: `stvx'
You didn't mention the binutils version or how it was configured. It
I hope subscribers to this list will be interested in a generalised
language toolkit that I have published under Gnu GPL. The toolkit is
written in the D language using the gdc D language frontend to gcc, and
it includes the beginnings of a GENERIC interface with gcc4, as well as
an interface t
For fun, I counted the number of open missed-optimization issues:
all versions: 423
gcc-3.4.x: 55
gcc-4.0.x: 170
gcc-4.1-x: 93
It looks like many of them, even those filed four
years ago, are getting some recent attention,
which is encouraging. Thanks to everyone
pushing these along.
- Dan
--
On Mon, 15 Aug 2005, Andrew Pinski wrote:
> This should been already fixed by:
> 2005-08-15 Sebastian Pop <[EMAIL PROTECTED]>
> PR 23386
> [...]
> What is happening here is we were miss-compiling a finite loop to be an
> infinite loop.
Thanks for the pointer, Andrew.
On Mon, 15 Aug 2005
31 matches
Mail list logo
