Re: GCC build goes into endless loop
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, Diego Novillo wrote: > I got something similar on last night's build, but it seems to > have been fixed now. How recent is your tree? It looked as if it was more recent then Sebastian's fix, but I found that due to some gcc.gnu.org or network hickup not everything was completely up-to-date; tonights automated build on the same machine suceeded again. 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? Gerald
missed-optimization issue count
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 -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
beginnings of a gcc interface for the language machine
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 to libtcc, the tiny C compilation library. The toolkit itself is at http://languagemachine.sourceforge.net This is a complete rewrite of software that I developed and used in real projects over a long period that began in 1975. The software consists of: * a shared library which implements the grammatical engine * a minimal main program * several different flavours of a metalanguage compiler * an application that generates the web pages from wiki-style text * a D language processor with a D language generator backend * examples including forward polish, reverse polish and infix calculator examples * an infix calculator example that compiles C code for immediate execution using libtcc * experiments with a gcc interface The language machine is intended to be useful across a wide range of applications, from quick'n'dirty text mungers upwards - anything that has a linguistic or grammatical component. The LMN metalanguage compiles to rules wrapped as shebang scripts, to rules wrapped in the C and D languages, and to rules compiled as (slightly odd) C and D language procedures, and it's quite easy to call external procedures in the C and D languages. A nice feature is that the source text format is compatible with wikimedia markup conventions, so some of the web pages (including the metalanguage definition) are generated directly from the LMN source text. The beginnings of an interface to gcc4 can be found at http://languagemachine.sourceforge.net/gcc_interface.html The infix calculator that directly generates and executes C code using libtcc is at http://languagemachine.sourceforge.net/tcc_calc.html The neat thing about the language machine is that it lets you play directly with the fundamentals of language. The engine can generate a diagram that explains exactly how rules are applied: it turns out that an engine that directly and efficiently implements the most general kind of recognition grammar is very much like a macro processor that lets you define your own syntax as part of the macro definition. It does this in a way that lets you concentrate on recognising and transforming patterns that happen to contain nonterminal symbols. Going at it this way, you can do everything from lexical analysis to code generation. In technical terms, the language machine directly implements analytic or recognition grammars with absolutely no restriction on the kind of rewriting rules that you can usefully use - each side of a rule can contain any number of symbols, and either side can usefully be empty. There is an explanation of how this approach fits into accepted ideas about language at http://languagemachine.sourceforge.net/grammar.html I hope some of you will share my excitement at the possiblities that can arise when this beast has a live interface to the GCC code generators, and that some of you can help make it happen. Peri Hankey -- http://languagemachine.sourceforge.net - The language machine
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 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 GNU assembler 2.16.91 20050809 Bintutils used the same configure script as what I used for gcc. I've been reading (googling) up on this problem as it seems I am not the first to have it. The problem also seems quite complicated. Binutils was configured with (among other options) "--with-cpu=7400" and "--enable-altivec". It can and does compile altivec instructions fine. It's just I can't get gcc and xgcc to pass that to the assembler. I thought the "--with-cpu" option was supposed to do that? i.e. default to 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? Maybe I'll also ask folks on the binutils mailing list. There is a TARGET_LIBGCC2_CFLAGS that is used when compiling libgcc2 instead of the normal CFLAGS_FOR_TARGET. You could add extra -m options here. That would solve your immediate problem, but you still would have a mismatch between gcc and binutils. It didn't work for me but I could have something else preventing it from working. Fred
RE: ppc assembler problem
-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 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 GNU assembler 2.16.91 20050809 Bintutils used the same configure script as what I used for gcc. I've been reading (googling) up on this problem as it seems I am not the first to have it. The problem also seems quite complicated. Binutils was configured with (among other options) "--with-cpu=7400" and "--enable-altivec". It can and does compile altivec instructions fine. It's just I can't get gcc and xgcc to pass that to the assembler. I thought the "--with-cpu" option was supposed to do that? i.e. default to 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? Maybe I'll also ask folks on the binutils mailing list. < ernesto **> Also, try the crossgcc mailing list <*** ernesto **> > There is a TARGET_LIBGCC2_CFLAGS that is used when compiling libgcc2 > instead of the normal CFLAGS_FOR_TARGET. You could add extra -m options > here. That would solve your immediate problem, but you still would have > a mismatch between gcc and binutils. It didn't work for me but I could have something else preventing it from working. Fred
Re: GCC build goes into endless loop
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 failure with hppa64-hp-hpux11.11 (natively). The other 2 targets build fine now. -- Marcel Moolenaar[EMAIL PROTECTED]
Re: GCC build goes into endless loop
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. Does it work for you as well now? I still have the failure with hppa64-hp-hpux11.11 (natively). The other 2 targets build fine now. Works for CodeSourcery just fine: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00931.html Are you sure that you are building with "make bootstrap". -- Pinski
Re: GCC build goes into endless loop
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.11. I haven't had time to analyze the problem, though. Does it work for you as well now? I still have the failure with hppa64-hp-hpux11.11 (natively). The other 2 targets build fine now. Works for CodeSourcery just fine: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00931.html Ok, thanks for the pointer. I'll double-check and try to spot the differences. For now, it's probably best to assume it's something local here. Are you sure that you are building with "make bootstrap". Positive. -- Marcel Moolenaar[EMAIL PROTECTED]
Re: How do I delete redundant prologue/epilogue instructions?
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 doubt that any port does this optimization. You would have to redo the bulk of reload: register elimination, assigning stack slot addresses, recomputing frame size and register save offsets, etc. Gcc isn't set up to do this. In the simplest case, if you have no locals, no frame pointer, no alloca, no outgoing args on the stack, etc, then a simple RTL scan of the function may prove that SP/FP/AP are never used, allowing us to remove code in the prologue and epilogue. However, I'm skeptical that this would occur often enough to be useful. And it would require some target dependent code to figure out how to do the rewrites, which may make this complicated. It is probably easier to try to avoid this situation, by getting better register allocation earlier. Make sure that the caller-save registers occur before the callee-save registers in REG_ALLOC_ORDER. Verify that the caller-save.c code which is used in reload is working for your target. We could try moving some of the regrename optimizations to before reload. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [PATCH]: Proof-of-concept for dynamic format checking
"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.
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
no modifiers. So we can get pretty good mileage out of a mechanism
which simply says "like printf, plus these conversions".
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.
Unfortunately it turns out that this doesn't currently describe the
BFD formatting. The BFD additional conversion specifiers %A and %B
can only appear at the beginning of the string, before any other
conversion specifiers. But still this would be good enough for many
uses.
The second approach is of course to write a little language which is
powerful enough to describe printf. The state machine language I
described earlier is too simple and perhaps overly cryptic. It would
be easier to understand a language based on regular expressions (which
are of course equivalent to state machines). The main issues I see
are:
* There is duplicated information in printf flags. For example, in
many cases we want to accept a width flag, and warn if the it is
zero. We don't want to have to duplicate that warning for each
conversion specifier which uses a width flag.
* The use of dollar to specify a particular argument (e.g., "%1$d")
must be represented cleanly. The dollar style must be used with
every conversion or with none. "%1$*2$d" is a particularly annoying
construct.
* It might be convenient to be able to access the current standard
level. It might also be convenient to access specific warning
options.
So let's consider a little language in which each conversion specifier
is described by a simplified regular expression. In order to handle
commonalities, we permit the regular expressions to use subroutines--a
subroutine is itself a named regular expression. Each regular
expression may have a conditional indicating whether it is valid,
which may reference the standard level and warning options. Each
regular expression may have an action which is executed if it matches.
The action is a sequence of zero or more predefined functions. Dollar
specifiers are handled specially by the framework, not by the little
language itself.
In this proposal, we can't use standard regular expressions, because
they have no provision for the subroutines which I think we need. So
here is the regular expression syntax:
c where c is not a meta-character, matches c
\c matches c
[abc...] matches any of the characters abc
r1r2 matches r1, then r2
(r)grouping; matches r
r* matches zero or more of r
r+ matches one or more of r
r? matches zero or one r
{NAME} matches a regular expression matched by {NAME}
{$}matches [0123456789]+$, and handles dollar specifier
The meta-characters are "\*+?[](){}/:" (colon is used for labels).
Typical regular expression items which are not present (but which we
could add if we want them): ^ and $ anchors, . to match any character,
| for alternation, [^abc...] for a negated match.
The grammar of the little language is:
rules: rule rules
rule: optcond optlabel '/' REGEXP '/' optactions
optcond: /* empty */ | '?' cond '?'
cond: VAR | cond '||' cond | cond '&&' cond | '(' cond ')'
optlabel: /* empty */ | ':' NAME ':'
optactions: /* empty */ | '{' actions '}'
actions: action actions
action: FNNAME '(' args ')' ';'
args: arg | arg ',' args
arg: STRING
We permit multiple regular expressions to have the same name. In this
case we try to match each one in order, and apply the actions of the
first one to match.
Conditionals are expressions based on variables, like flag_isoc99.
I'm not sure yet what the permitted variables should be.
The string is processed by matching unnamed regular expressions in
order, anchored at the start of the string. If nothing matches, the
character is ignored and we start matchin at the next character.
So, for printf:
:FLAGS: /[#0- +]*/
:WIDTH: /[123456789][0123456789]*/
:WIDTH: /\*{$}/ { match (int); }
:PREC: /.[0123456789]*/
:PREC: /\*{$}/ { match (int); }
:ADJ: /{FLAGS}{WIDTH}?{PREC}?/
?flag_isoc99? /%{ADJ}hh[di]/ { match (char); }
/%{ADJ}h[di]/ { match (short); }
?flag_isoc99? /%{ADJ}ll[di]/ { match (long long); }
/%{ADJ}l[di]/ { match (long); }
/%{ADJ}[di]/{ match (int); }
etc. Note that the use of {$} in the regexp controls which argument
is tested by the next call to "match".
As an example of checking for a zero fiel
Re: [PATCH]: Proof-of-concept for dynamic format checking
* 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.?
Re: [PATCH]: Proof-of-concept for dynamic format checking
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.
Re: [PATCH]: Proof-of-concept for dynamic format checking
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 constant folding etc.? I don't really see how that could work and still do what we want it to do. Could you give an example of what it would look like? Ian
Re: Help with GCC
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 unless you have a combined register allocator and instruction scheduler. We don't have that. They are separate passes. Combining them is difficult. We do have life time info at the RTL instruction level, but this info tends to be either internal to each register allocation pass, or not specific enough for your needs. You may or may not be able to do anything with this info. The register allocator does not emit instructions (other than reloads emitted by reload), so you can't do this in the register allocator. You probably have to do this in final, when RTL is emitted as assembly language. You might be able to do something useful with REG_DEAD notes, but they are probably not guaranteed to be accurate when we get to final. You could try scanning following instructions for REG_DEAD notes, to see where registers die. Worst case, you might have to create your own life time info by scanning all of the RTL instructions in a function. You could do this in a MACHINE_DEPENDENT_REORG pass. You will probably need to spend some time studying the gcc sources in order to do anything useful here. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: ppc assembler problem
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 handle right. When you use the -m7400 option, gcc will pass -maltivec to the assembler. When you use --with-cpu=7400 at configure time, gcc should pass -maltivec to the assembler by default. This is apparently not happening, and is probably a gcc bug. ASM_SPEC would have to be modified to fix this. You may be able to do this manually by creating a spec file and editing it to add the missing -maltivec option to the assembler specs. You may want to report this problem into the gcc bugzilla database so it gets tracked and fixed. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: --target=v850-unknown-elf, linker problem
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 bugzilla database. See http://gcc.gnu.org/bugs.html We are volunteers, and can't always answer every question immediately. You should not expect mail set on Saturday to be answered before Monday morning. Generally, you should allow a week before assuming a message was missed. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [PATCH]: Proof-of-concept for dynamic format checking
* 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 execute it at compile time using constant folding etc.?
>
> I don't really see how that could work and still do what we want it to
> do. Could you give an example of what it would look like?
If I understand your %A/%B example correctly, it would look like this:
/* FORMAT is the complete format string, POS the offset of the current %
directive. Returns a C type specifcier as a string. NULL means: do not
consume any argument */
static inline const char *
printf_checker_bfd (const char *format, size_t pos)
{
if (strncmp (format + pos, "%A", 2) == 0)
{
if (pos != 0)
{
__builtin_warn ("`%A' must occur at the start of the format string");
return "void *"; // accept anything
}
return "asection *";
}
if (strncmp (format + pos, "%B", 2) == 0)
{
if (pos != 0)
{
__builtin_warn ("`%B' must occur at the start of the format string");
return "void *"; // accept anything
}
return "bfd *";
}
return __builtin_printf_checker (format, pos); // handle printf format string
}
#pragma GCC format "bfd" "invoke printf_checker_bfd"
The interface still needs some polishing; it might be desirable to be
able to pass along some kind of flag. Perhaps it's more obvious to
express the scanning loop in the checking code and explicitly compare
the type using some builtin, but this is probably even more
challenging on the optimiziers.
Re: --target=v850-unknown-elf, linker problem
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 sent to gcc-patches. In general, we would need a gcc copyright assignment, but this is simple enough that we don't need one for this patch. Alternatively, patches can be put into bugzilla bug reports. This will help make sure it won't get forgotten. In this case, since you've already sent the patch, and it looks good, I'll try to take care of this for you. I'm doing a v850 build now to verify it and then I plan to add it to gcc mainline so this will be fixed for the next gcc release, gcc-4.1. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [PATCH]: Proof-of-concept for dynamic format checking
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 going to somehow fully unroll that loop at compile time? Ian
Re: [PATCH]: Proof-of-concept for dynamic format checking
* 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 going to write a loop, and is gcc going to somehow fully > unroll that loop at compile time? This is indeed a problem (with GCC 4.0 at least). A regexp builtin which returns the length of the matched string probably could probably solve this. Managing state so that you can still compose multiple checkers is the harder part, I think.
Hi I want to implement new target AVR MCU's for GCC
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
Re: Hi I want to implement new target AVR MCU's for GCC
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 like to implement new AVR targets, which files are involved? gcc/config/avr would be the canonical place to go looking for files to edit.
Re: Hi I want to implement new target AVR MCU's for GCC
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 implement new AVR targets, which files are involved? # # Who knows, maby I can contribute :-) # # /Best Regards Rikard Str?mmer #
Re: [PATCH]: Proof-of-concept for dynamic format checking
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 have a sane way to (partially) execute optimizers at -O0 without screwing up with the pass manager too much? Probably they can be talked into, but might require some work. The idea is neat though, and I prefer it over introducing a specific pattern-matching language (which sounds like over-engineering for such a side feature). Giovanni Bajo
Re: [PATCH]: Proof-of-concept for dynamic format checking
"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 optimizers at -O0 without > screwing > up with the pass manager too much? Probably they can be talked into, but might > require some work. The idea is neat though, and I prefer it over introducing a > specific pattern-matching language (which sounds like over-engineering for > such > a side feature). I suppose I have the reverse opinion about which one is over- engineering, but that's probably just me. Remember that it's not enough simply to execute the optimizers. You have to build a symbol table and an environment for the code to execute in. Another approach would be to dlopen a shared library to do format checking. There might be some security implications to that, though. Ian
Re: [PATCH]: Proof-of-concept for dynamic format checking
> 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 > no modifiers. So we can get pretty good mileage out of a mechanism > which simply says "like printf, plus these conversions". I like having a shorthand, however looking at the GCC sources custom formats many of them want something much simpler than printf but with several extra flags. For example, gcc's asm_fprintf format implements "l" long and "ll" long long as length modifiers, plus an extension "w" for gcc's HOST_WIDE_INT. However it does not implement C90 "h" or the C99 or GNU extention length modifiers (e.g. "z" or "Z" for size_t). Ditto for the gcc diagnostic formats. Specifiers themselves are also a mixed bag. The asm_fprintf format doesn't implement %p or the floating point specifiers. But of course it has a bunch of it's own extension flags. So clearly many implementations will need a language to specify exactly what they do. Alternatively or maybe in addition, we could have a way to say "like printf, but delete these specifiers, and these modifiers. Then add these other things." Ultimately if a complete language is available as well as "like printf" then users will do whichever is easier given their particular format. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: [PATCH]: Proof-of-concept for dynamic format checking
> 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 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 routine will not change it's behavior based on the C standard in effect when compiling it. Therefore if we implement an inherit, it should force the user to choose "inherit printf90", "inherit printf99" or "inherit printfGNU". Or something along those lines. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: [PATCH]: Proof-of-concept for dynamic format checking
"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 routine will not change it's > behavior based on the C standard in effect when compiling it. > > Therefore if we implement an inherit, it should force the user to > choose "inherit printf90", "inherit printf99" or "inherit printfGNU". > Or something along those lines. 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 --std= flag used at compile time of the user's code. Ian
Re: [PATCH]: Proof-of-concept for dynamic format checking
> 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 --std= flag used at compile time of the user's code. > Ian Yeah, BFD can only do that because it forces the %A %B specifiers be in the front. (Maybe inheriting the morphing printf is your trigger for enforcing front position for all exended specifiers? Or is that too esoteric for users?) Anyway, I conclude we need both fixed and the adjustable inheriting. So "inherit printf" for BFD and "inherit printf90" (etc) for other implementations. That's easy enough to code up. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: [PATCH]: Proof-of-concept for dynamic format checking
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 ("section %d is called %A", sec, 1);
--
Alan Modra
IBM OzLabs - Linux Technology Centre
Re: --target=v850-unknown-elf, linker problem
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 it, I'll put the bug report and patch into bugzilla." (I shoulda made it a separate para. :-) > In this case, since you've already sent the patch, and it looks good, > I'll try to take care of this for you. It'll only take me a moment, and "try" fits poorly with "make sure it won't get forgotten". ;-) (Sorry, the years with quality system responsibilities are showing through.) > I'm doing a v850 build now to verify it and then I plan to add it to > gcc mainline so this will be fixed for the next gcc release, gcc-4.1. If you haven't put it in bugzilla yet, I can free you up for the more important next gcc release. Regards, Erik
