Re: Char shifts promoted to int. Why?
The operand of the shift operator is of type unsigned int.
"x <<= c" is exactly the same as "((int)x) << c"
It doesn't matter whether the promotion is explicit or implicit, the
semantics
are the same.
According to C99, the operand of the shift operator should be "integer
type", which includes "char", "short", "int", "long", or "long long". So
the operand of shift opertor is not necessarily to be unsigned int.
But on the other hand, C99 also requires the "integer promotions are
performed on each of the (bitwise shift operator's) operands", so the
integer promotion should be performed.
- Original Message -
From: "Paul Brook" <[EMAIL PROTECTED]>
To:
Cc: "Paul Schlie" <[EMAIL PROTECTED]>
Sent: Sunday, December 17, 2006 10:19 PM
Subject: Re: Char shifts promoted to int. Why?
On Monday 18 December 2006 01:15, Paul Schlie wrote:
Chris Lattner wrote:
> On Dec 17, 2006, at 12:40 PM, Rask Engelmann Lamberts wrote:
>> I seem unable to get a QImode shift instruction from this code:
>>
>> unsigned char x;
>>
>> void qishifttest2 (unsigned int c)
>> {
>>x <<= c;
>> }
>>
>> should have been generated. Also, notice the redundant zero
>> extension.
>> Why are we not generating a QImode shift instruction?
>
> Consider when c = 16. With the (required) integer promotion, the
> result
> is defined (the result is zero). If converted to QImode, the shift
> would
> be undefined, because the (dynamic) shift amount would be larger
> than the
> data type.
??? A left shift >= the precision of its shifted unsigned operand can
only
logically result in a value of 0 regardless of its potential
promotion.
Shifting >= the size of the value being shifted can and do give
nonzero
results on common hardware. Typically hardware will truncate the shift
count.
eg. x << 8 implemented with a QImode shift will give x, not 0.
Although integer promotion as specified by C may technically be
performed
lazily as a function of the implicit target precision required for a
given
operation, GCC tends to initially promote everything and then attempt
to
determine if an operation's precision may be subsequently lowered
after
having already lost critical knowledge of its originally specified
operand's precision.
No. You're confusing some language you just invented with C.
The operand of the shift operator is of type unsigned int.
"x <<= c" is exactly the same as "((int)x) << c"
It doesn't matter whether the promotion is explicit or implicit, the
semantics
are the same.
Paul
Re: Inserting profiling function calls
Hi, Patrice,
I don't know about inserting call at the basic block level, but I am
quite sure inserting calls at the function level could be done by
aspect-oriented-programming (AOP).
For example, we used our project, AspectC compiler (www.aspectc.net), to
weave in following aspect into gcc,
#include
before():call($ $(...)){
fprintf(stderr, "%s\n", this->funcName);
}
What it does is just to print out name of every functions called inside
gcc during execution time.
Our experiment shows that gcc makes 637929 function calls in order to
compile following program into machine code:
#include
void main(){
char *cool = "cool";
printf("%s\n",cool);
}
And the function names, ordered by calling sequence, are :
---
main
xmalloc_set_program_name
unlock_std_streams
unlock_1
unlock_1
unlock_1
gcc_init_libintl
alloc_args
xmalloc
xmalloc
xmalloc
xmalloc
process_command
xstrdup
xmalloc
make_relative_prefix
lbasename
lrealpath
split_directories
save_string
save_string
save_string
save_string
save_string
save_string
split_directories
..
maybe_unlink
unlink_if_ordinary
lstat
pex_free
pex_unix_cleanup
delete_temp_files
delete_if_ordinary
stat
delete_if_ordinary
stat
--
This is just a simple aspect. More advanced aspect, like memory
profiling, can be easily done by AOP. The cool thing is that those extra
code is totally modularized in aspect, ie. not a single piece of code
will go into gcc code base.
Just an alternative.
Thanks.
Mike
- Original Message -
From: "GERIN Patrice" <[EMAIL PROTECTED]>
To: "Jan Hubicka" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, February 08, 2007 5:56 PM
Subject: Re: Inserting profiling function calls
Would you for a start please
explain what do you need to do that can't be done using existing arc
and
value profiling?
Sorry, my first mail was not clear about the goal.
Objectives are to follow the execution of function and basic block at
execution time.
To do this, we plan to insert function call, like mcount is inserted
at the function level for gprof but at the basic block level.
A user library linked with the application can then implement this
functions.
Thank you,
Patrice
___
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et
son interface révolutionnaire.
http://fr.mail.yahoo.com
Re: Inserting profiling function calls
- Original Message -
From: "Frank Ch. Eigler" <[EMAIL PROTECTED]>
To: "Michael Gong" <[EMAIL PROTECTED]>
Cc: "GERIN Patrice" <[EMAIL PROTECTED]>; "Jan Hubicka"
<[EMAIL PROTECTED]>;
Sent: Saturday, February 10, 2007 10:21 AM
Subject: Re: Inserting profiling function calls
"Michael Gong" <[EMAIL PROTECTED]> writes:
I don't know about inserting call at the basic block level, but I am
quite sure inserting calls at the function level could be done by
aspect-oriented-programming (AOP). [...]
Another possibility, coming soon[1], is to use systemtap[2] probes:
% stap -e 'probe process("./a.out").function("*") { log
(probefunc()) }'
Among major differences between this approach and AOP are:
- no recompilation of the target program is required: it's more like
running a quick background scriptable debugger
- the instrumentation instead would be inserted into the
programs on the fly via breakpoints, probably overall slower
- we rely on OS kernel facilities for those breakpoints,
which means Linux only at this time
- the instrumentation (log...) language is rubber-padded and safe
- there can be no interference amongst concurrently running
instrumentation packages, or upon the main program: it's
non-intrusive
Current AOP approachs, either AspectC or AspectC++, are source-code
level weaving, ie. they are implemented as a source-to-source
transformation tool.
1. They can insert functions , called advice, in the locations which can
be specified by the programmer. So the insertion locations are quite
flexible. For example, programmer can insert functions only in the
control flow of some functions.
2. The advice code can access the parameter or the return value of the
functions, and use or modify them inside advice functions.
3. The inserted codes by AspectC are thread-safe.
FWIW, yet another technology possibility I know of for this sort of
data collection is frysk[3].
- FChE
[1] "coming soon" == as soon as those kernel facilities allow
ptrace-style breakpoint insertion into user space. At this time,
we can only probe the kernel proper.
[2] http://sources.redhat.com/systemtap/
[3] http://sources.redhat.com/frysk/
ACC Release V 0.5: Get Aspect-oriented through acc!
Hi, We are pleased to announce the release of AspeCt-oriented C (ACC) V 0.5, formerly known as AspectC. Besides some new features, the ACC 0.5 release also includes a set of experimental weave adapters that help integrate aspeCts in the build process of large C-based software projects. For more details and download, please visit http://www.aspectc.net. Highlights of ACC V 0.5 include: o ACC demo at AOSD'07 this week (Wednesday & Friday) o A set of experimental weave adapters to integrate ACC into large builds o Debugging support and improved error reporting o A set of course assignments applying ACC in the curriculum of a 3rd year Operating Systems course (available from our web site). We appreciate feedback and support for AspeCt-oriented C. Regards, ACC Team www.aspectc.net March 12, 2007
Gcc extension: have a semicolon after a function definition ??
Hi,
I am wondering why following program is compiled successfully by gcc ?
Please notice there is a ";" after the function definition.
Is there a gcc extension for it ?
/* foo.c */
int main() {
printf("hello world\n");
} ;
Thanks.
Michael
Re: Gcc extension: have a semicolon after a function definition ??
Yes. Gcc gives a warning under -pedantic. gcc -pedantic foo.c foo.c:3: warning: ISO C does not allow extra `;' outside of a function It looks like an old C syntax. Regards, Michael - Original Message - From: "Andrew Pinski" <[EMAIL PROTECTED]> To: "Michael Gong" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; Sent: Tuesday, August 08, 2006 4:34 PM Subject: Re: Gcc extension: have a semicolon after a function definition ?? Hi, I am wondering why following program is compiled successfully by gcc ? Please notice there is a ";" after the function definition. Is there a gcc extension for it ? Yes, use -pedantic-errors for showing if it is a GCC extension or not. -- Pinski
Re: preprocessing question
One explanation could be:
- Original Message -
From: "Jan Beulich" <[EMAIL PROTECTED]>
To:
Sent: Monday, September 25, 2006 11:23 AM
Subject: preprocessing question
Can anyone set me strait on why, in the following code fragment
int x(unsigned);
struct alt_x {
unsigned val;
};
#define xalt_x
#define alt_x(p) x(p+1)
since "x" is already defined as a object-like macro, "x" is replaced by
"alt_x", so this essentially is: #define alt_x(p) alt_x(p+1)
Since C99 (6.10.3.9) describes:
... defines an object-like macro that causes each subsequent instance of the
macro name to be replaced by the replacement list of preprocessing tokens
that constitute the remainder of the directive.
Since the "x" in the replacement list of "alt_x" macro definition is a
"subsequent instance of the macro name", so it is replaced by "x"'s
replaement list, which is "alt_x".
int test(struct x *p) {
return x(p->val);
}
the function invoked in test() is alt_x (rather than x)? I would have
expected that the preprocessor
- finds that x is an object like macro, and replaces it with alt_x
- finds that alt_x is a function-like macro and replaces it with x(...)
- finds that again x is an object like macro, but recognizes that it
already participated in expansion, so doesn't replace x by alt_x a
second time.
Our compiler team also considers this misbehavior, but since I
tested three other compilers, and they all behave the same, I
continue to wonder if I'm mis-reading something in the standard.
Thanks a lot, Jan
Re: preprocessing question
Yes. You are right.
- Original Message -
From: "Andreas Schwab" <[EMAIL PROTECTED]>
To: "Michael Gong" <[EMAIL PROTECTED]>
Cc: "Jan Beulich" <[EMAIL PROTECTED]>;
Sent: Monday, September 25, 2006 12:08 PM
Subject: Re: preprocessing question
"Michael Gong" <[EMAIL PROTECTED]> writes:
One explanation could be:
- Original Message -
From: "Jan Beulich" <[EMAIL PROTECTED]>
To:
Sent: Monday, September 25, 2006 11:23 AM
Subject: preprocessing question
Can anyone set me strait on why, in the following code fragment
int x(unsigned);
struct alt_x {
unsigned val;
};
#define xalt_x
#define alt_x(p) x(p+1)
since "x" is already defined as a object-like macro, "x" is replaced by
"alt_x", so this essentially is: #define alt_x(p) alt_x(p+1)
Since C99 (6.10.3.9) describes:
... defines an object-like macro that causes each subsequent instance of
the macro name to be replaced by the replacement list of preprocessing
tokens that constitute the remainder of the directive.
Macro expansion does not operate on preprocessing directives unless noted
otherwise.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
AspeCt-oriented C (ACC) Release V 0.6
Hi, We are pleased to announce the release of AspeCt-oriented C (ACC) V 0.6. The ACC 0.6 release includes some experimental features and a new script "tacc" for automatically integrating aspect-compilation in building large C-based software projects. For more details and download, please visit http://www.aspectc.net. Highlights of ACC V 0.6 include: 1. preturn() statement inside advice, allowing advice functions to return immediately from the function containing the matched join point 2. try() pointcut, catch() advice and throw() statment, allowing the adding of exception handling to the core systems via aspects 3. support for "fileName" and "targetName" to the thisJoinPoint structure. 4. introduce a new set of compiler tools, including "tacc" and "accmake". We appreciate feedback and support for AspeCt-oriented C. Additional slides for presenting and promoting ACC are available from our web site. Finally, with ACC V0.6, ACC is able to bootstrap itself. Regards, ACC Team ( www.aspectc.net ) May 30, 2007
