Roberto Bagnara <[EMAIL PROTECTED]> writes:
> My reading, instead, is that C99 requires unsigned long long int
> to have exactly the same number of bits as long long int.
Yes, that's correct. Sorry, I got confused between C89
(which is what that Tandem NSK version supports) and C99.
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> Or you can do, since elsewhere in the code you compute time_t_max:
>> for (j = 1; j <= time_t_max / 2 + 1; j *= 2)
>
> No, this does not work. It would work to have:
>
> for (j = 1;;)
> {
> if (j > time_t_max / 2)
> break;
>
Jack Howarth wrote:
I noticed that in gcc trunk and gcc 4.2 branch
that multilib builds of zlib occur. Does gcc
actually use the multlib zlib?
Not for the host zlib.
For instance on
x86_64 linux does the 32-bit zlib get used or on
Darwin does the 64-bit zlib get used? We are
considering us
Paul Eggert <[EMAIL PROTECTED]> writes:
> * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> optional second argument specifying the default optimization
> options for GCC. These optimizations now default to "-O2 -fwrapv"
> instead of to "-O2". This partly at
>
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
> > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> > optional second argument specifying the default optimization
> > options for GCC. These optimizations now default to "-O2 -fwrapv"
> > instead of to "-O2". This pa
As per the subject. The upcoming merge of toplevel libgcc will only
work either for disabled bootstrap, or with the toplevel bootstrap
mechanism. For this reason, we are now disabling "../configure
--disable-bootstrap && make bootstrap". The correct way to bootstrap is
to just use "./configu
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Paul Eggert <[EMAIL PROTECTED]> writes:
| >
| > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > > optional second argument specifying the default optimization
| > > options for GCC. These optimizations now default to "-
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Paul Eggert <[EMAIL PROTECTED]> writes:
|
| > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > optional second argument specifying the default optimization
| > options for GCC. These optimizations now default to "-O2 -fw
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > Paul Eggert <[EMAIL PROTECTED]> writes:
> | >
> | > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> | > > optional second argument specifying the default optimization
> | > > options for GCC.
On Dec 13, 2006, at 17:09, Denis Vlasenko wrote:
# g++ -c -O3 toto.cpp -o toto.o
# g++ -DUNROLL -O3 toto.cpp -o toto_unroll.o -c
# size toto.o toto_unroll.o
textdata bss dec hex filename
525 8 1 534 216 toto.o
359 8 1 368 170 to
On Thu, 14 Dec 2006, Basile STARYNKEVITCH wrote:
> I really think that such information should go into GCC internal
> documentation, where I was not able to find it out. Do you believe
> that some of the descriptions in this thread and in the Wiki page just
> cited should go into the documentation?
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | >
| > | > Paul Eggert <[EMAIL PROTECTED]> writes:
| > | >
| > | > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
| > | > > optional second argument specifying the
>
> | > If the above is the only without Autoconf change, I would highly
> | > recommend Autoconf change if GCC optimizers highly value benchmarks
> | > over running real world code.
> |
> | Which one, mine or Paul's?
>
> If what you propose is the only way out, and there is no way to make
> GCC
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | > If the above is the only without Autoconf change, I would highly
| > | > recommend Autoconf change if GCC optimizers highly value benchmarks
| > | > over running real world code.
| > |
| > | Which one, mine or Paul's?
| >
| > If what you pro
On 29 Dec 2006 07:55:59 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Paul Eggert <[EMAIL PROTECTED]> writes:
> * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
> optional second argument specifying the default optimization
> options for GCC. These optimizati
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| In fact, what they told me was that since they made their change in
| 1991, they have had *1* person who reported a program that didn't
| work.
And GCC made the change recently and got yy reports. That might say
something about both compiler
On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| In fact, what they told me was that since they made their change in
| 1991, they have had *1* person who reported a program that didn't
| work.
And GCC made the chan
On Fri, 15 Dec 2006, Paolo Bonzini wrote:
>>> http://gcc.gnu.org/install/build.html
> The counter quote is obviously wrong, thanks for the report.
If I see this correctly, Mike's quote came from our installation
documentation in gcc/doc/install.texi. Are you going to have a
stab at that, based o
Daniel Berlin wrote:
I'm sure no matter what argument i come up with, you'll just explain it away.
The reality is the majority of our users seem to care more about
whether they have to write "typename" in front of certain declarations
than they do about signed integer overflow.
I have no idea
On 12/29/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> I'm sure no matter what argument i come up with, you'll just explain it away.
> The reality is the majority of our users seem to care more about
> whether they have to write "typename" in front of certain declarations
>
> > 1) For the function foo10:
> > The if-block following "if( i == 15 )" will be never executed since
> > 'i' will never become 15 here. So, this entire block could be
> > removed without changing the semantics. This would improve the
> > program execution since the if-condition does not need to b
Christian Sturn <[EMAIL PROTECTED]> writes:
> Thank you for your answer. Is there any chance to have gcc dump out
> an optimized code in the form the source level language, e.g. can I run
> gcc with some optimizations and see how the compiler modified my C
> source code?
You can get an approxima
Ian Lance Taylor wrote:
Christian Sturn <[EMAIL PROTECTED]> writes:
Thank you for your answer. Is there any chance to have gcc dump out
an optimized code in the form the source level language, e.g. can I run
gcc with some optimizations and see how the compiler modified my C
source code?
You
On Fri, 29 Dec 2006 15:03:51 -0500
Robert Dewar <[EMAIL PROTECTED]> wrote:
> > There is no support for dumping actual valid source code, though,
> > and it is unlikely that there ever will be.
>
> And indeed it is not in general possible, there are many optimizations
> that cannot be expressed in
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Daniel Berlin" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | In fact, what they told me was that since they made their change in
| > | 1991, they have had *1* pers
On 29 Dec 2006 20:15:01 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| On 29 Dec 2006 19:33:29 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Daniel Berlin" <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | In fact, what they told me
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| Basically, your argument boils down to "all supporting data is wrong,
Really?
Or were you just
# You can have all the sarcasm you want, but maybe instead of sarcasm,
Otherwise, you have a serious problem hearing anything contrary to
your
> For this _specific_ instance of the general problem, C++ users could
> use numeric_limits::max() and get away with it, but I don't
> believe such a solution (or the one you propose or similar I've seen)
> to this specific instance generalizes to portable, readable and
> maintainable solution to t
On 29 Dec 2006 21:04:08 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| Basically, your argument boils down to "all supporting data is wrong,
Really?
Or were you just
# You can have all the sarcasm you want, but maybe instead of sarcasm
Christian Sturn <[EMAIL PROTECTED]> writes:
> On Fri, 29 Dec 2006 15:03:51 -0500
> Robert Dewar <[EMAIL PROTECTED]> wrote:
>
> > > There is no support for dumping actual valid source code, though,
> > > and it is unlikely that there ever will be.
> >
> > And indeed it is not in general possible,
Ian Lance Taylor wrote:
I fully appreciate that there is a real problem here which needs to be
addressed, but this does not seem like the best solution to me. A
great number of C programs are built using autoconf. If we make this
change, then they will all be built with -fwrapv. That will disa
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> I fully appreciate that there is a real problem here which
> needs to be addressed, but this does not seem like the
> best solution to me.
I agree. It's meant to be a stopgap. I support coming up
with a better solution than the stopgap.
> The resu
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Does anybody think that Paul's proposed patch to autoconf would be
> better than changing VRP?
I don't.
I haven't noticed anyone else addressing this question,
which I think is a good one.
I don
* Andrew Pinski:
>> If what you propose is the only way out, and there is no way to make
>> GCC optimizers reasonable, then I believe Paul's proposal is the next
>> option.
>
> But that still does not address the issue is that this is not just about
> GCC any more since autoconf can be used many
* Daniel Berlin:
> OTOH, people who rely on signed overflow being wraparound generally
> *know* they are relying on it.
> Given this seems to be some small number of people and some small
> amount of code (since nobody has produced any examples showing this
> problem is rampant, in which case i'm
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> (BTW, I would be somewhat disappointed if this had to be pampered over
> on the autoconf side. If the GNU project needs -fwrapv for its own
> software by default, this should be reflected in the compiler's
> defaults.
I absolutely
On Fri, 29 Dec 2006, Daniel Berlin wrote:
[...]
> OTOH, people who rely on signed overflow being wraparound generally
> *know* they are relying on it.
Wrong. Many people have relied on that "feature" because they thought it
was leagal and haven't had the time to check every piece of code they
wrot
On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> (BTW, I would be somewhat disappointed if this had to be pampered over
> on the autoconf side. If the GNU project needs -fwrapv for its own
> software by default, this shou
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> Nobody has yet showed that any significant number of
> programs actually rely on this undefined behavior.
GCC itself relies on wrapv semantics. As does glibc. And
coreutils. And GNU tar. And Python. I'm sure there are
many other significant progr
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
[...]
| This is so funny coming from you it's ridiculous.
You have decided to get personal, that certainly will elevate the
debate I suppose.
I don't see what is so funny about you coming and declaring minority
any voice, data that go contrary to you
> Richard Guenther wrote:
>> Robert Dewar wrote:
>>> Daniel Berlin wrote:
>>> I'm sure no matter what argument i come up with, you'll just explain it
>>> away. The reality is the majority of our users seem to care more about
>>> whether they have to write "typename" in front of certain declaration
Paul Eggert wrote:
In practice, I expect that most C programmers probably
assume wrapv semantics, if only unconsciously. The minimal
C Standard may not entitle them to that assumption, but they
assume it anyway. Part of this is the Java influence no
doubt. Sorry, but that is just the way the
Snapshot gcc-4.1-20061229 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061229/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> Next week, after the merge, the bootstrap rules in the gcc directory
> will go away.
So what will be the way at that point to bootstrap JUST gcc?
On Fri, Dec 29, 2006 at 05:53:43PM -0500, Richard Kenner wrote:
> > Next week, after the merge, the bootstrap rules in the gcc directory
> > will go away.
>
> So what will be the way at that point to bootstrap JUST gcc?
You won't be able to do that any more. We've been saying that since
the fir
> You won't be able to do that any more. We've been saying that since
> the first top level bootstrap rules went in, every time the subject
> came up - this really shouldn't be a surprise.
No, what's been said is that there will be a MODE in which that can't
be done, but it was always claimed tha
In article <[EMAIL PROTECTED]> you write:
>I don't think doing any of both is a good idea. Authors of the affected
>programs should adjust their makefiles instead - after all, the much more
>often reported problems are with -fstrict-aliasing, and this one also doesn't
>get any special treatment by
> Specifically, because we value reliability over speed and strict
> standard conformance...
Seems to me that programs that strictly meet the standard of the language
they are written in would be more reliable than programs that are written
in some ill-defined language.
I've been beating my head against the wall over this for hours.
Does anybody know how to fix this error? I've googled it to death, it
turns up alot but I can't find a fix that works.
I build cross compilers all the time with 3.4 and have never run into
this. I recently switched to 4.x.
I'm tr
Is your target a newlib target? If so, are you including --with-newlib?
> Wrong. Many people have relied on that "feature" because they thought it
> was leagal and haven't had the time to check every piece of code they
> wrote for conformance with the holy standard. And they don't have the time
> now to walk trough the work of their lifetime to see where they did wrong
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> Authors of the affected programs should adjust their makefiles
That is what the proposed patch is for. It gives a way for
developers to adjust their makefiles.
A developer of portable software cannot simply put something
like this into a makefile
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> the much more often reported problems are with
> -fstrict-aliasing, and this one also doesn't get any
> special treatment by autoconf.
That's a good point, and it somewhat counterbalances the
opposing point that -O2 does not currently imp
> On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
>> I think it would be a very bad choice for the GNU project to work
>> around itself. If we can't come to an agreement on the list,
>> please ask the Steering Committee. This is a textbook example of
>> what they're for.
The issue doe
> I'm not sure what data you're asking for.
Here's the data *I'd* like to see:
(1) What is the maximum performance loss that can be shown using a real
program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
one assumes wrapping semantics?
(2) In the current SPEC, how many prog
On Fri, Dec 29, 2006 at 06:46:09PM -0500, Richard Kenner wrote:
> > Specifically, because we value reliability over speed and strict
> > standard conformance...
> Seems to me that programs that strictly meet the standard of the language
> they are written in would be more reliable than programs th
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> -O2 does not currently imply '-ffast-math'ish optimizations even
>> though the C standard would allow it to.
>
> Can you point me to the relevant section/paragraph in C99 standard
> where it allows
>
> C has been a portable assembler for years before it got normalized and
> optimizing compilers took over.
18 years. And now it has been 17 years since C has been standardized so
you can say C has been standardized now for half its life. 18 years is a
long time when it comes to computers. I
>
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
>
> > Nobody has yet showed that any significant number of
> > programs actually rely on this undefined behavior.
>
> GCC itself relies on wrapv semantics. As does glibc. And
> coreutils. And GNU tar. And Python. I'm sure there are
> many othe
[EMAIL PROTECTED] (Richard Kenner) writes:
> (1) What is the maximum performance loss that can be shown using a real
> program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
> one assumes wrapping semantics?
>
> (2) In the current SPEC, how many programs benefit from undefined ov
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
"Seongbae Park" <[EMAIL PROTECTED]> writes:
> On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
>> -O2 does not currently imply '-ffast-math'ish optimizations even
>> though the C standard would allow it to.
>
> Can you point me to the releva
Paul Eggert wrote:
> I don't feel a strong need for 'configure' to default to
> -fstrict-aliasing with GCC. Application code that violates
> strict aliasing assumptions is often unportable in practice
> for other reasons, and needs to be rewritten anyway, even if
> optimization is disabled. So -f
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > C has been a portable assembler for years before it got normalized and
| > optimizing compilers took over.
|
| 18 years. And now it has been 17 years since C has been standardized so
| you can say C has been standardized now for half its life.
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> | >
> | > C has been a portable assembler for years before it got normalized and
> | > optimizing compilers took over.
> |
> | 18 years. And now it has been 17 years since C has been standardized so
> | you can say C has been standardized now f
>> GCC itself relies on wrapv semantics. As does glibc. And
>> coreutils. And GNU tar. And Python. I'm sure there are
>> many other significant programs. I don't have time to do a
>> comprehensive survey right now.
>
> Where does GCC rely on that? I don't see it anywhere?
It's not like the
Marc Espie wrote:
Specifically, because we value reliability over speed and strict
standard conformance...
Still as a long term goal, it would be good to try to have your
C programs written in C, and not some ill-defined dialect thereof!
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | >
| > | > C has been a portable assembler for years before it got normalized and
| > | > optimizing compilers took over.
| > |
| > | 18 years. And now it has been 17 years since C has been st
Richard Kenner wrote:
Specifically, because we value reliability over speed and strict
standard conformance...
Seems to me that programs that strictly meet the standard of the language
they are written in would be more reliable than programs that are written
in some ill-defined language.
In t
DJ Delorie wrote:
Is your target a newlib target? If so, are you including --with-newlib?
Thanks, that was the problem.
Why isn't --with-newlib the default for newlib targets?
> Why isn't --with-newlib the default for newlib targets?
--with-newlib *tells* us that it's a newlib target.
DJ Delorie wrote:
Why isn't --with-newlib the default for newlib targets?
--with-newlib *tells* us that it's a newlib target.
Well not knowing what a newlib target was when you asked, I looked in
configure.in.
It seems that if it's not a newlib target then target-newlib is missing
from n
On Fri, Dec 29, 2006 at 06:38:27PM -0500, Richard Kenner wrote:
> > You won't be able to do that any more. We've been saying that since
> > the first top level bootstrap rules went in, every time the subject
> > came up - this really shouldn't be a surprise.
>
> No, what's been said is that there
On 30 Dec 2006 03:20:11 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
...
The C standard, in effect, has an appendix (Annex H) that was not
there in the C89 edition, and that talks about the very specific issue
at hand
H.2.2 Integer types
[#1] The signed C integer types int,
> > > Specifically, because we value reliability over speed and strict
> > > standard conformance...
>
> > Seems to me that programs that strictly meet the standard of the language
> > they are written in would be more reliable than programs that are written
> > in some ill-defined language.
>
>
On 12/29/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I'm not sure what data you're asking for.
Here's the data *I'd* like to see:
(1) What is the maximum performance loss that can be shown using a real
program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
one assumes wrap
On 12/29/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 12/29/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > I'm not sure what data you're asking for.
>
> Here's the data *I'd* like to see:
>
> (1) What is the maximum performance loss that can be shown using a real
> program (e.g,. one in SPE
Just to address the other compiler issue
No, they will work on other compilers, since 'configure'
won't use -O2 with those other compilers.
icc defaults to -O2 without any options, so unless you are passing
-O0, it will enable this.
Unless you know of some real-world C compiler that breaks
> Those questions are more for the opponents of -fwrapv, so
> I'll let them answer them. But why are they relevant?
> Having -fwrapv on by default shouldn't affect your SPEC
> score, since you can always compile with -fnowrapv if the
> application doesn't assume wraparound.
(1) If -fwrapv isn't t
> But since you asked, I just now did a quick scan of
> gcc-4.3-20061223 (nothing fancy -- just 'grep -r') and the first
> example I found was this line of code in gcc/stor-layout.c's
> excess_unit_span function:
>
> /* Note that the calculation of OFFSET might overflow; we calculate it so
>
> I don't believe anyone else considers this important.
The history on this sort of thing is that people don't pay attention
until it happens and then everybody starts yelling about bootstrap
time increasing ...
> - Build supporting libraries for the build system tools
> - Build supporting l
> which clearly says LIA-1 isn't a requirement - notice "if" in the
> second setence.
> H.1 makes it clear that the entire Annex H doesn't add any extra rule
> to the language but merely describes what C is in regard to LIA-1.
> H.2 doubly makes it clear that C as it defined isn't LIA-1
> - again,
[EMAIL PROTECTED] (Richard Kenner) writes:
> > I don't believe anyone else considers this important.
>
> The history on this sort of thing is that people don't pay attention
> until it happens and then everybody starts yelling about bootstrap
> time increasing ...
>
> > - Build supporting lib
Richard Kenner wrote:
which clearly says LIA-1 isn't a requirement - notice "if" in the
second setence.
H.1 makes it clear that the entire Annex H doesn't add any extra rule
to the language but merely describes what C is in regard to LIA-1.
H.2 doubly makes it clear that C as it defined isn't LIA
> Would you feel OK if there were a make target to do a bootstrap
> without building the other target libraries?
Yes. That would only be a small increase in time (libiberty).
> If not, this is seriously confused, lia-1 is MUCH more than just
> wrapping integer types.
Then indeed there is confusion here. It was sounding to me like GCC
would already had support for lia-1, but just needed to define signed
overflows. If GCC does not and will not support lia-1, why are we
On Sat, Dec 30, 2006 at 12:30:06AM -0500, Richard Kenner wrote:
> > - Build supporting libraries for the build system tools
> > - Build supporting libraries for the host system tools
> > - Build gcc
> > - [NEW] Build libgcc
> > - If stage < final stage, go back to building some of the hos
Once upon a time, the --disable-bootstrap configure option wasn't
necessary. "make" built gcc, and "make bootstrap" bootstrapped it.
Is this behavior useful? Should we have it back again?
The trivial implementation is to build separate makefiles using the
existing sed magic and have the non-boo
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> Just to address the other compiler issue
>>
>> No, they will work on other compilers, since 'configure'
>> won't use -O2 with those other compilers.
>
> icc defaults to -O2 without any options, so unless you are passing
> -O0, it will enable this.
Tha
> Once upon a time, the --disable-bootstrap configure option wasn't
> necessary. "make" built gcc, and "make bootstrap" bootstrapped it.
>
> Is this behavior useful? Should we have it back again?
Doesn't "make all-gcc" already do that? Or do you mean including the target
libraries?
Thanks,
An
>> Nor would I relish the prospect of keeping wrapv assumptions out of
>> GCC as other developers make further contributions, as the wrapv
>> assumption is so natural and pervasive.
>
> It's neither natural not pervasive to me! I would never write code
> that way
That's great, but GCC has had man
90 matches
Mail list logo
