On 2005-04-05, at 16:12, Nix wrote:
I could turn the question back: What's so hard about grepping the
source?
Because one does not expect to find compilation flags embedded in the
source?
One does - if not grown up in the limited gcc "community". All the high
scale
compilers out there DO IT.
B
[Cc: list drastically trimmed.]
On Tue, 5 Apr 2005, Marcin Dalecki spake:
> On 2005-04-05, at 01:28, Nix wrote:
>> On 4 Apr 2005, Marcin Dalecki stipulated:
>>> I don't agree with the argument presented by Geert Bosch. It's even more
>>> difficult to
>>> muddle through the atrocities of autoconf/
On 2005-04-05, at 01:28, Nix wrote:
On 4 Apr 2005, Marcin Dalecki stipulated:
I don't agree with the argument presented by Geert Bosch. It's even
more difficult to
muddle through the atrocities of autoconf/automake to find the places
where compiler
switches get set in huge software projects
What'
On 4 Apr 2005, Marcin Dalecki stipulated:
> I don't agree with the argument presented by Geert Bosch. It's even more
> difficult to
> muddle through the atrocities of autoconf/automake to find the places where
> compiler
> switches get set in huge software projects
What's so hard about
find . \
On 2005-04-04, at 19:46, Dale Johannesen wrote:
On Apr 3, 2005, at 5:31 PM, Geert Bosch wrote:
On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I
explained that the various optimization p
On Apr 3, 2005, at 5:31 PM, Geert Bosch wrote:
On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I
explained that the various optimization passes, while theoretically
orthogonal, are not
On Sun, Apr 03, 2005 at 04:25:00PM +0200, Kai Henningsen wrote:
> Well, yes and no - I sometimes think that gcc doesn't have *enough* knobs.
Lots of knobs <=> inadequate testing and failures when users issue a
combination of knob settings that have never been tested.
That's why I find Gentoo rath
Georg Bauhaus wrote:
Though what GCC does for a compilation unit with Ada's pragma
Optimize(Off); inside it is close to what some users seem to be wanting
in C.
GCC does complain about an attempt to translate the program below
with optimization turned on:
$ gcc -gnatv -c -O2 opt.adb
...
2.
On Apr 1, 2005, at 16:36, Mark Mitchell wrote:
In fact, I've long said that GCC had too many knobs.
(For example, I just had a discussion with a customer where I
explained that the various optimization passes, while theoretically
orthogonal, are not entirely orthogonal in practice, and that truni
Robert Dewar wrote:
A little note is that Ada has a pragma Opimize that would make
use of this feature (it's currently pretty much ignored).
Though what GCC does for a compilation unit with Ada's pragma
Optimize(Off); inside it is close to what some users seem to be wanting
in C.
GCC does complain
[EMAIL PROTECTED] (Mark Mitchell) wrote on 01.04.05 in <[EMAIL PROTECTED]>:
> In fact, I've long said that GCC had too many knobs.
>
> (For example, I just had a discussion with a customer where I explained
> that the various optimization passes, while theoretically orthogonal,
> are not entirely
A little note is that Ada has a pragma Opimize that would make
use of this feature (it's currently pretty much ignored).
On Sat, Apr 02, 2005 at 08:29:48PM +0200, Gerald Pfeifer wrote:
> On Fri, 1 Apr 2005, Joe Buck wrote:
> > Unfortunately, where there is a good argument for not using empty loops
> > as busy-waits, at one time it was documented GCC behavior that it would
> > work, so we can't really blame the users
On Fri, 1 Apr 2005, Joe Buck wrote:
> Unfortunately, where there is a good argument for not using empty loops
> as busy-waits, at one time it was documented GCC behavior that it would
> work, so we can't really blame the users for trusting the doc.
However, it's really a looong time since we clari
E. Weddington wrote:
What do you get if you use the C99 construct of declaring the variable
in the for statement? Like so:
for(volatile int i = 0; i < COUNT; ++i);
I get the same code afaics.
In fact, I haven't been able to produce an empty loop that
isn't translated into an actual loop, volatile
Gabriel Dos Reis wrote:
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i < COUNT; ++i)
| ;
This must be an FAQ. The above is no way of (no matter how popular
the urban legend makes it) implementing delay.
As a normative statement, a busy loop might not be the
w
On 2005-04-01, at 23:36, Mark Mitchell wrote:
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user t
On 2005-04-01, at 23:17, Richard Guenther wrote:
On Apr 1, 2005 11:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Dale Johannesen wrote:
Agree. (And documentation will be written.)
Yay. It sounds like we're definitely on the same page. I think that
as
long as we keep the semantics clear, this
Joe Buck wrote:
Georg Bauhaus <[EMAIL PROTECTED]> writes:
| A busy-loop function is used to effect a delay, not too precise,
| but portably. Like
|
| #define COUNT 1000
|
| void f() {
|/*volatile*/ /*register*/ int i;
|
|for (i = 0; i < COUNT; ++i)
| ;
Unfortunately, wh
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Georg Bauhaus <[EMAIL PROTECTED]> writes:
>> | A busy-loop function is used to effect a delay, not too precise,
>> | but portably. Like
>> |
>> | #define COUNT 1000
>> |
>> | void f() { | /*volatile*/ /*register*/ int i;
>> |
>>
Georg Bauhaus <[EMAIL PROTECTED]> writes:
> | A busy-loop function is used to effect a delay, not too precise,
> | but portably. Like
> |
> | #define COUNT 1000
> |
> | void f() {
> |/*volatile*/ /*register*/ int i;
> |
> |for (i = 0; i < COUNT; ++i)
> | ;
On Sat, Apr 02, 200
Georg Bauhaus <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| > Are you using "volatile" correctly? There are situations where "volatile"
| > alone does not suffice and you need more locking, but the Linux and BSD
| > kernel folks manage to optimize their device driver code.
|
| We have just
Georg Bauhaus wrote:
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop function is used to effect a delay, not too precise,
but portably. Like
#define COUNT 1000
void f() {
/*volatile*/ /*register*/ int i;
for (i = 0; i < COUNT; ++i)
;
}
If volatile is used
Joe Buck wrote:
Are you using "volatile" correctly? There are situations where "volatile"
alone does not suffice and you need more locking, but the Linux and BSD
kernel folks manage to optimize their device driver code.
We have just been discussing a similar topic in a de.* newsgroup.
A busy-loop
Richard Guenther wrote:
On Apr 1, 2005 11:23 PM, E. Weddington <[EMAIL PROTECTED]> wrote:
Is your objection to a grain finer than the function level? Or is it to
the whole concept of having pragmas change the optimization level per
function?
It would be a general objection - I thought we're
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user trying to override it (and hereby maybe only
wo
On Apr 1, 2005 11:23 PM, E. Weddington <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >But the question is, do we want all this sort of #pragmas? It would
> >surely better to improve the compilers decisions on applying certain
> >optimizations. As usual, in most of the cases the compil
Richard Guenther wrote:
But the question is, do we want all this sort of #pragmas? It would
surely better to improve the compilers decisions on applying certain
optimizations. As usual, in most of the cases the compiler will be
smarter than the user trying to override it (and hereby maybe only
wo
On Apr 1, 2005 11:07 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Dale Johannesen wrote:
> > Agree. (And documentation will be written.)
>
> Yay. It sounds like we're definitely on the same page. I think that as
> long as we keep the semantics clear, this will be useful functionality.
>
> >>
Dale Johannesen wrote:
Agree. (And documentation will be written.)
Yay. It sounds like we're definitely on the same page. I think that as
long as we keep the semantics clear, this will be useful functionality.
That's what I assumed. Anything finer than that is insane. :-)
Actually there are
On Apr 1, 2005, at 11:24 AM, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about
this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that
negatively.
Well, in theory nobody can bl
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
| > Dale Johannesen wrote:
| >
| > >So I guess question 1 is, Mark, do you feel negatively enough about this
| > >feature to block its acceptance in mainline?
| >
| > I'm not sure that I *c
Richard Guenther wrote:
On Apr 1, 2005 9:36 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Diego Novillo wrote:
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its accepta
On Apr 1, 2005 9:36 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Diego Novillo wrote:
> > On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
> >
> >>Dale Johannesen wrote:
> >>
> >>
> >>>So I guess question 1 is, Mark, do you feel negatively enough about this
> >>>feature to block its
On Friday, April 1, 2005, at 10:16 AM, Kelly Murphy wrote:
There's the case where we'd like to have the files of a subsystem to
be optimized but we want a handful of functions that directly access
hardware be unoptimized. (We found that the optimization did some
write reordering that the hardware
Diego Novillo wrote:
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that negative
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
> Dale Johannesen wrote:
>
> >So I guess question 1 is, Mark, do you feel negatively enough about this
> >feature to block its acceptance in mainline?
>
> I'm not sure that I *could* block it, but, no, I don't feel that negatively.
>
Dale Johannesen wrote:
So I guess question 1 is, Mark, do you feel negatively enough about this
feature to block its acceptance in mainline?
I'm not sure that I *could* block it, but, no, I don't feel that negatively.
I think that a #pragma (or attribute) that affects only optimization
options is
On Fri, Apr 01, 2005 at 10:16:44AM -0800, Kelly Murphy wrote:
> I know we'd find something like that really handy for some of the
> embedded stuff we're doing.
>
> There's the case where we'd like to have the files of a subsystem to
> be optimized but we want a handful of functions that directly a
I know we'd find something like that really handy for some of the
embedded stuff we're doing.
There's the case where we'd like to have the files of a subsystem to
be optimized but we want a handful of functions that directly access
hardware be unoptimized. (We found that the optimization did some
Dale Johannesen <[EMAIL PROTECTED]> writes:
> I've currently got the job of implementing pragma(s) to change
> optimization level in the middle of a file. This has come up a few
> times before,
Would it be possible to make it a function attribute? I would
really like to have
void __attribute__(
Dale Johannesen <[EMAIL PROTECTED]> writes:
> For mainline I assume we'll need "GCC" to the syntax; that local
> change is small compared to making it work though.)
If you're implementing a #pragma for compatibility with another
compiler, we don't require the "GCC" prefix.
zw
I've currently got the job of implementing pragma(s) to change
optimization level in the middle of a file. This has come up a few
times before,
http://gcc.gnu.org/ml/gcc/2001-06/msg01275.html
http://gcc.gnu.org/ml/gcc/2002-09/msg01171.html
http://gcc.gnu.org/ml/gcc/2003-01/msg00557.html
and so f
43 matches
Mail list logo
