Duncan Sands <[EMAIL PROTECTED]> writes:
[...]
| Ada semantics require INT_MIN rem -1 to be zero.
I cannot see any other value as a result.
-- Gaby
On Tue, 16 Jan 2007, Joe Buck wrote:
| On Tue, Jan 16, 2007 at 12:05:12PM -0600, Gabriel Dos Reis wrote:
| > By definition, the absolute value of "a % b" is always less than the
| > absolute value of b. Consequently, "a % b" is always defined.
|
| Nitpick: for nonze
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Jan 16, 2007 at 11:05:20AM -0800, David Daney wrote:
| > Roberto Bagnara wrote:
| > >
| > >Hmmm, it says nothing about the remainder. Can some Google guru
| > >suggest how to prove or disprove the claim that what we are
| > >talking about is wildly k
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| > To be clear, in my opinion, this should always be selected by an
| > option, it should never be default behaviour for any target.
|
| I disagree. One should get correct results by default.
Onc
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| >
| > | On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
| > | > To be clear, in my opinion, this should always be selected by an
| > | > option, it should never be default behaviour for any targ
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Ian Lance Taylor writes:
| > Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| >
| > > Ian, do you believe something along the line of
| > >
| > > # > I mean, could not we generate the following for "%
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| > On Wed, 17 Jan 2007, Andrew Haley wrote:
| >
| > |
| > | From a performance/convenience angle, the best place to handle this is
| > | either libc or the kernel.
| >
| > Hmm, that is predicat
On Wed, 17 Jan 2007, Andrew Haley wrote:
[...]
| > | "To a man with a hammer, all things look like a nail." It's very
| > | tempting for us in gcc-land always to fix things in gcc, not because
| > | it's technically the right place but because it's what we control
| > | ourselves.
| >
| >
On Wed, 17 Jan 2007, Andrew Haley wrote:
| Gabriel Dos Reis writes:
| > On Wed, 17 Jan 2007, Andrew Haley wrote:
| >
| > [...]
| >
| > | > | "To a man with a hammer, all things look like a nail." It's very
| > | > | tempting for us in gcc-land a
On Wed, 17 Jan 2007, Joe Buck wrote:
| On Wed, Jan 17, 2007 at 07:42:38PM +, Andrew Haley wrote:
| > Gabriel Dos Reis writes:
| > > You believe there is one solution, except that it does not work for
| > > the supported target.
| >
| > Sorry, I don't understand wh
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| >In the case of the containers, we are asserting/relying on the fact that
| >the pointer difference is zero or positive. But this has become a
| >widespread idiom: people write their own code in the STL style. If STL
| >code now ha
On Wed, 17 Jan 2007, Richard Guenther wrote:
| On 17 Jan 2007 16:36:04 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > Paolo Carlini <[EMAIL PROTECTED]> writes:
| >
| > | Joe Buck wrote:
| > |
| > | >In the case of the containers, we are asserting/relyi
On Wed, 17 Jan 2007, Joe Buck wrote:
| On Wed, Jan 17, 2007 at 04:36:04PM -0600, Gabriel Dos Reis wrote:
| > I just built firefox (CVS) with GCC mainline. The compiler spitted
| > avalanches of non-sensical warning about conversions signed ->
| > unsigned may alter values, when
On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > ... thanks a lot Gaby both for your practical and theoretical
| > investigations into this issue, both right to the point! Now, in my
| > opinion, we should simply remove the bits about sign
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Robert Dewar <[EMAIL PROTECTED]> writes:
|
| > Ian Lance Taylor wrote:
| >
| > > We do want to generate a trap for x / 0, of course.
| >
| > Really? Is this really defined to generate a trap in C?
| > I would be surprised if so ...
|
| As far as I
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Wed, 17 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | On 17/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > | > ... thanks a lot Gaby both for you
Gabriel Paubert <[EMAIL PROTECTED]> writes:
| On Wed, Jan 17, 2007 at 04:15:08PM -0800, Ian Lance Taylor wrote:
| > Robert Dewar <[EMAIL PROTECTED]> writes:
| >
| > > Ian Lance Taylor wrote:
| > >
| > > > We do want to generate a trap for x / 0, of course.
| > >
| > > Really? Is this really def
On Thu, 18 Jan 2007, Joseph S. Myers wrote:
[...]
| > Furthermore, elsewhere (in the overflow thread) it has been suggested
| > that people should convert to the unsigned variants, do computations there,
| > and convert back to the signed variants. We have just promised an
| > invariant that we
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | Does that apply also to:
| > |
| > | unsigned int y = -10;
| >
| > Yes.
| >
|
| Then, why Wcon
On Wed, 17 Jan 2007, Andrew Pinski wrote:
| >
| > One use of -Wconversion is to draw attention to
| >
| >int x = 2.3; // warning: be careful, is this what you want?
| > // this is a potential bug as it is value altering.
| >
| > and in an upcoming revision to C++, it is ver
On Wed, 17 Jan 2007, Mike Stump wrote:
| On Jan 17, 2007, at 4:44 PM, Gabriel Dos Reis wrote:
| > C++ forces compilers to reveal their semantics for built-in types
| > through numeric_limits<>. Every time you change the behaviour,
| > you also implicilty break an ABI.
|
| No, t
On Thu, 18 Jan 2007, Andrew Haley wrote:
| Robert Dewar writes:
| > Joe Buck wrote:
| >
| > (off topic!)
| >
| > > On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
| > >> H .. I wish some of the more important bugs in gcc received
| > >> the attention that this very unimpor
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Richard Guenther wrote:
|
| > Providing a __builtin_assert () function is still one thing on my
| > TODO, we can
| > derive proper ASSERT_EXPRs from it in VRP even in the -DNDEBUG case.
|
| Great! Certainly could be profitably used in libstdc++.
Indee
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
[...]
| > As the PR you noted, it wasn't part of C++.
| >
|
| You are wrong.
"the PR you noted" is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3
which you described as your favorite. The PR starts with this
gcc reports the signedne
On Thu, 18 Jan 2007, Paolo Carlini wrote:
| Manuel --
|
| > I read it and still don't get it. We know we should not warn about
| > system headers but we do and that is a known bug. So again, why is
| > libstdc++ using Wconversion at all?
|
| I appreciate your help with this issue, and I'm confiden
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| I just felt that the conversation was going in the direction of "we
| should shut the warnings of Wconversion up because people using it
| will get warnings for libstdc++".
I'm afraid you did not read the conversation carefully.
-- Gaby
On Thu, 18 Jan 2007, Robert Dewar wrote:
| Gabriel Dos Reis wrote:
|
| > The pragma thing will be fixed; however, we will still be left with
| > unhelful warning for what has become idiomatic because of the way C++
| > tends to see sequences.
|
| In Ada, we changed things a while ag
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > [...]
| >
| > | > As the PR you noted, it wasn't part of C++.
| > | >
| > |
| > | You
Hi,
There were over 250 PRs open against GCC-4.0.4. Almost all of
them are "benign" in the sense that we can leave without fixing them
in GCC-4.0.4 -- many are already fixed in more recent versions.
I'm now giving attention only to those PRs marked as blocker or
critical. I've identified thre
On Thu, 25 Jan 2007, Richard Guenther wrote:
| You might want to consider middle-end/28651 given the recent integer overflow
| discussions.
Good suggestion!
| I can do the backport work if you like.
If you could work out a backport by tomorrow morning (CST), that would
would great.
Thanks!
--
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| A summary of what has been proposed so far to clean up Wextra follows.
| Please, your feedback is appreciated. And reviewing patches even more
| ;-)
Thanks for this digest; I'd give your feedback tonight.
-- Gaby
Volker Reichelt <[EMAIL PROTECTED]> writes:
| Hi,
|
| > There were over 250 PRs open against GCC-4.0.4. Almost all of
| > them are "benign" in the sense that we can leave without fixing them
| > in GCC-4.0.4 -- many are already fixed in more recent versions.
| > I'm now giving attention only to
On Thu, 25 Jan 2007, Manuel López-Ibáñez wrote:
| Thanks. I understand that you are busy with the 4.0.4 release, so
| don't need to hurry up!
I was busy with daytime job.
-- Gaby
On Thu, 25 Jan 2007, Richard Guenther wrote:
| On 1/25/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 25 Jan 2007, Richard Guenther wrote:
| >
| > | You might want to consider middle-end/28651 given the recent integer
overflow
| > | discussions.
| >
| > Good
On Thu, 25 Jan 2007, Joe Buck wrote:
| It might be worth fixing a couple of wrong-code bugs that are already
| fixed in 4.1 and have very trivial fixes. I don't think it's wise,
| though, to backport fixes from the 4.1 branch that are broken in 4.1.1
| unless there's a really strong justification
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| On 23/01/07, Joe Buck <[EMAIL PROTECTED]> wrote:
| > On Tue, Jan 23, 2007 at 07:52:30PM +, Manuel López-Ibáñez wrote:
| > > * A base class is not initialized in a derived class' copy constructor.
| > >
| > > Proposed: move this warning to -Wu
Please consider the GCC-4.0.4 as frozen. No non-documentation
check-in is permitted. For documentation check-in, please consult
with me first.
Thanks,
-- Gaby
Hi,
The tarballs for GCC-4.0.4 are available for download at
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.4-20070129/
Please download and test them. Baring any major problem, the final
release will be made withing 3 days. And the GCC-4.0.x series will be
definitely closed.
-- Gaby
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| On Sun, 28 Jan 2007, Joe Buck wrote:
| > It's probably time to turn off 4.0 snapshots; the last ones will
| > probably be Gaby's prerelease snapshots, and the release should come
| > soon.
|
| That's a good idea. You're right, there is no need to wait
would like to thank the impressive number people who
contributed to this release.
--
Dr. Gabriel Dos Reis ([EMAIL PROTECTED]), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Texas A&M University -- Department of Computer Science
301, Bright Building -
Andi Kleen <[EMAIL PROTECTED]> writes:
| "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
| >
| > And we don't want to arm our detractors with bad SPEC numbers. I can just
| > imagine the FUD spreading... we've got to fix it or backout.
|
| For me as a gcc user miscompilations are far worse than ba
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| On 06/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
| > Manuel López-Ibáñez wrote:
| > > On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
| > >> After reviewing all of the traffic[1] that stemmed from my previous
| > >> status report, I've
On Wed, 7 Mar 2007, Manuel López-Ibáñez wrote:
| Should we mention Waddress in the GCC 4.2 release notes?
Proper documentation is sufficient I believe.
-- Gaby
"Doug Gregor" <[EMAIL PROTECTED]> writes:
Am I the only one to receive Doug's recent messages with empty body?
-- Gaby
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
| On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > we are unavoidably
| > adding tree codes and we must solve the issue, one way or another.
|
| Another real solution would perhaps be to not use 'tree' for front end
| specific data structures
Paolo Carlini <[EMAIL PROTECTED]> writes:
| In my opinion, "visions" for a better future do not help here.
And here we are. :-)
-- Gaby
Nicholas Nethercote <[EMAIL PROTECTED]> writes:
| On Mon, 19 Mar 2007, Doug Gregor wrote:
|
| >> > It's going to have a big performance impact. To extract a 9-bit value,
| >> > the compiler will need to do a lot of masking every time it accesses
| >> > the TREE_CODE.
| >>
| > So, about 16% slower
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
[...]
| I'm sorry to ask such a (probably naive) question, but do someone have a
| precise idea of the performance strengths and weaknesses of GCC and of other
| opensource compilers (like LLVM, Open64, TinyCC, ...) or even compiler for
| different
"Doug Gregor" <[EMAIL PROTECTED]> writes:
[...]
| and optimize than yesterday's. No, I don't want my compiler to be 5%
| slower, but I'll give up 5% for better standards conformance and
| improved code generation.
similar justifications for yet another small% of slowdown have been
given routinel
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > similar justifications for yet another small% of slowdown have been
| > given routinely for over 5 years now. small% build up; and when they
| &
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| "Simon Brenner" <[EMAIL PROTECTED]> writes:
|
| > I propose to implement incremental parsing in C++ (through hand-waving, C++
has
| > been decided to be the language most in need of incremental parsing),
similar to
| > the approach in article [1].
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| On 23/03/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > > In which case, the companies concerned, rather than the individuals,
| > > are volunteers: they have no contractual obligation to the FSF. Marc
| > > Espie's argument stands.
| >
| > I
Martin Michlmayr <[EMAIL PROTECTED]> writes:
| * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
| > So if you are seeing this in C++, the change was intentional because
| > PR24924 was fixed. If you are seeing it in C and you are not using
| > pedantic-errors, then it is probably a bu
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > Martin Michlmayr <[EMAIL PROTECTED]> writes:
| >
| > | * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]:
| > | > So if you are seeing this in
Martin Michlmayr <[EMAIL PROTECTED]> writes:
| * Gabriel Dos Reis <[EMAIL PROTECTED]> [2007-03-27 09:33]:
| > -pedantic asks for strict checking of rules. User should accept
| > correcting their codes (or used codes) with they ask for strict
| > checking.
|
| They didn
Florian Weimer <[EMAIL PROTECTED]> writes:
| * Manuel López-Ibáñez:
|
| > C++ preprocessor emits errors by default for nonconformant code,
| > following the C++ frot-end default behaviour.
|
| Neither the C standard nor the C++ standard imposes any requirements
| on concrete source code represen
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Mar 27, 2007 at 02:23:47PM +0100, Manuel López-Ibáñez wrote:
| > On 27/03/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote:
| > >* Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 14:08]:
| > >> C++ preprocessor emits errors by default for nonconform
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Tue, 27 Mar 2007, [EMAIL PROTECTED] wrote:
|
| > my understanding of pedwarn (since over a decade) is I explained.
| > Now, if we do have some good diagnostics, we should not lose them,
| > as a matter of restoring the traditional meaning of pedw
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 27 Mar 2007 21:11:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > | In C, a pedwarn is a warning by default, an error with -pedantic-errors.
| > |
| > | In C++, a pedwarn is an error by default, a warning wi
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > I don't understand your statement. The C++ (and the C) standard says
| >
| > # If a source file that is not empty does not end in a new-line
| > # character, or ends in a new-line ch
David Daney <[EMAIL PROTECTED]> writes:
| One could argue that issuing some type of diagnostic (either at
| compile time or run time) would be helpful for people that don't
| remember to write correct code 100% of the time.
I raised this very issue a long time ago; a long-term GCC contributor
voc
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
[...]
| > The compiler should be able to eliminate many of the conditionals.
| Yes but no, there are cases that the compiler can't eliminate the
| conditionals that depend on run-time, e.g., "n" is non-constant parameter.
What is the performance penalty
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
| > Good points.
| >
| > Regarding negatives, I believe 'operator new' takes a size_t,
| > which is unsigned, but if it were signed it, the multiplication
| > would indeed be in danger of creating a negative.
| >
| > If possible, I would prefer a solution
"J.C. Pizarro" <[EMAIL PROTECTED]> writes:
[...]
| But if someone implements one fastest bucket-based quickallocator then
| the performance penalty with this check is considerable.
I would like to see the actual performance penalty numbers for such
thingy deployed in the real world.
-- Gaby
[EMAIL PROTECTED] (Ross Ridge) writes:
| Joe Buck writes:
| >If a check were to be implemented, the right thing to do would be to throw
| >bad_alloc (for the default new) or return 0 (for the nothrow new).
|
| What do you do if the user has defined his own operator new that does
| something else?
new that does
| >something else?
|
| Gabriel Dos Reis writes:
| >More precisely?
|
| Well, for example, like all other things that a new_handler can do,
| like throwing an exception derived from bad_alloc or calling exit().
| In addition, any number of side effects are possible, like p
Joe Buck <[EMAIL PROTECTED]> writes:
| This is why I suggested that, should we implement a better check,
| there should be an option to turn it off, so programmers who cannot
| afford an extra byte are taken care of.
I agree.
-- Gaby
[EMAIL PROTECTED] (Ross Ridge) writes:
[...]
| Gabriel Dos Reis writes:
| >I believe you're confused about the semantics.
| >The issue here is that the *size of object* requested can be
| >represented. That is independent of whether the machine has enough
| >memory or not. S
"Lawrence Crowl" <[EMAIL PROTECTED]> writes:
[...]
| Intel has had several popular processors with segmented addresses
| including the 8086, 80186, and 80286. (Actually, the 80386 and
| successors are segmented, but the operating systems typically hide
| that fact.) The also had the i432.
|
|
Diego Novillo <[EMAIL PROTECTED]> writes:
| Richard Henderson wrote on 04/10/07 21:19:
| > On Tue, Apr 10, 2007 at 08:48:27PM -0400, Diego Novillo wrote:
| >> Sure, but things will be different if/when the operands stop being 'tree'.
| >
| > We'll burn that bridge when we come to it.
|
| Works f
Thomas Koenig <[EMAIL PROTECTED]> writes:
| [adjusting Subject and also forwarding to [EMAIL PROTECTED]
|
| On Wed, 2007-04-18 at 12:12 -0700, Vivek Rao wrote:
| > Here is a feature of g95 that I would like to see in
| > gfortran. G95 assigns numbers to warnings and allows
| > selected warnings t
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| On Fri, 20 Apr 2007, Manuel López-Ibáñez wrote:
| > Not only that, but you can do -Werror -Wno-error=foo, to get errors
| > for everything except -Wfoo. Also, you can do
| > -fdiagnostics-show-options to find out which -Wfoo option generates
| > each wa
Jan Hubicka <[EMAIL PROTECTED]> writes:
[...]
| Basically we need to explain inliner that the abstraction functions are
| free to get sane results on C++...
\o/
[...]
| The only problem with common heuristics I see is that in C the "inline"
| keyword is very strong hint basically meaning
Mark Mitchell <[EMAIL PROTECTED]> writes:
| A few top-level comments on this thread:
|
| 1. The C++ community has split into two sub-communities. One is very
| heavily focused on template metaprogramming. The other is doing more
| "traditional" object-oriented programming. The kinds of program
Richard Guenther <[EMAIL PROTECTED]> writes:
[...]
| > Of course, if we can make the compiler automatically do the right thing,
| > that's great. What I'm proposing is a method that would be possibly
| > acceptable for 4.0 that would give people an easy to understand way of
| > getting the compi
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Feb 27, 2005, at 5:30 PM, Steven Bosscher wrote:
| > Interesting. You of course know Gaby is always claiming the exact
| > opposite: That the compiler must *honor* the inline keyword (explicit
| > or "implicit", ie. inline in class definitions), that
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
[...]
| > The kinds of programs
| > written by these two communities are drastically different, even
| > though, obviously, there is overlap between the two, mixed programs,
| > etc. But, programmers in one camp tend to think that their style is
| > "v
Steven Bosscher <[EMAIL PROTECTED]> writes:
[...]
| I can only wonder why we are having this discussion just after GCC 4.0
| was branched, while it was obvious already two years ago that inlining
| heuristics were going to be a difficult item with tree-ssa.
my recollection and own feeling is tha
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Nathanael Nerode wrote:
| >>> Nathanael Nerode wrote:
| > It's in now, BTW. Nothing broke. :-)
|
| We need to talk about that.
|
| Independently of whether or not I made the right decision, your
| decision to check in the patch undermined the process
Chris Lattner <[EMAIL PROTECTED]> writes:
| Karel Gardas wrote:
| > Yes, that's undefined, but I just define this class to be able to do:
| > Foo* f = dynamic_cast(x);
| > l = f->iiop_version();
| > there is nothing like delete involved. Anyway, I agree with you that
| > emit warning about this is
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| > It seems that the warning could be improved to be emitted when the
| > *delete* is seen of a class without a virtual dtor (but that does
| > have virtual methods). If you never actually do the questionable
| > behavior, you'd never get the warn
Joe Buck <[EMAIL PROTECTED]> writes:
| On Fri, Mar 04, 2005 at 08:06:27PM -0600, Chris Lattner wrote:
| > In my mind, the times you want to silence the warning (without defining
| > the virtual dtor) are when you *know* that it will never be used that way,
| > because it's part of the contract o
David Carlton <[EMAIL PROTECTED]> writes:
| On Fri, 04 Mar 2005 19:15:41 -0600 (CST), Chris Lattner <[EMAIL PROTECTED]>
said:
|
| > It's not a matter of warning vs not warning: it's a matter of
| > emitting bogus warnings *sometimes* when you can emit the proper
| > warning *all of the time*.
|
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Mark Mitchell <[EMAIL PROTECTED]> wrote:
|
| > IMO, if these are C++-only, it's relatively easy to deprecate these
| > extension -- but I'd like to hear from Jason and Nathan, and also the
| > user community before we do that. Of all the extensions w
Olivier Galibert <[EMAIL PROTECTED]> writes:
| On Wed, Mar 09, 2005 at 07:04:39AM +0100, Gabriel Dos Reis wrote:
| > That is a rather weak argument. What is the type of the argument if
| > it were possible?
|
| float obviously. You follow the standard promotion/type resolution
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| >>> IMO, if these are C++-only, it's relatively easy to deprecate these
| >>> extension -- but I'd like to hear from Jason and Nathan, and also the
|
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
| > The problem is x^0.0 (real exponent), not x^0 (integer exponent).
|
| Well, mathematically, you can distinguish these two functions:
|
| powrr: RxR -> R (not defined on (0,0) in particular)
|
|
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
|
| >> Because the example was just an example. In real code, "3" is probably a
| >> variable of integer type, and "4.0f" is probably a variable of fl
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > | Well, mathematically, you can distinguish these two functions:
| > |
| > | powrr: RxR -> R (not def
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Since there is no exact replacements
And that statement is false; and you do know that.
-- Gaby
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
| > No. I mean when I call powi() either through built-ins or appropriate
| > overload (several programming languages do so), I expect sane semantics.
|
| What is powi()? I couldn&
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 15:54:03 +0100, Gabriel Dos Reis wrote:
| > The C standard is not the holy bible and certainly does not define
| > everything. We're talking about compiler construction, here.
|
| This isn't just compiler constr
David Carlton <[EMAIL PROTECTED]> writes:
| On Thu, 10 Mar 2005 15:54:03 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> said:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > | On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
|
| > | > The asseryion that 0^0
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 15:29:49 +0100, Paolo Carlini wrote:
| > Vincent Lefevre wrote:
| > >What is powi()? I couldn't find it in the C standard. It isn't
| > >in the Linux man pages either.
| > >
| > ;) It's just a new builtin that we have in mainline, very us
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Gabriel Dos Reis wrote:
| > You probably noticed that in the polynomial expansion, you are using
| > an integer power -- which everybody agrees on yield 1 at the limit.
| >
| > I'm tlaking about 0^0, when you look at the limi
Paul Schlie <[EMAIL PROTECTED]> writes:
[...]
| > You've transmuted the function x^y to the function x^x which is a
| > different beast. Existing of limit of the latter does not imply
| > existance of limit of the former. Again check the counterexamples in
| > the message I referred to above.
|
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
| > You probably noticed that in the polynomial expansion, you are using
| > an integer power -- which everybody agrees on yield 1 at the limit.
| >
| > I'm tlaking about 0^
Paul Schlie <[EMAIL PROTECTED]> writes:
| > From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| > |Paul Schlie <[EMAIL PROTECTED]> writes:
| > | Thank you. In essence, I've intentionally defined the question of x^y's
| > | value about x=y->0 as a constrained &q
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-03-13 at 15:26 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| >
| > | On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote:
| > | > You probably noticed that in the polynomi
Robert Dewar <[EMAIL PROTECTED]> writes:
| Marc Espie wrote:
| > In article <[EMAIL PROTECTED]> you write:
| >
| >>Well as I said above, trampolines or an equivalent are currently critically
| >>needed by some front ends (and of course by anyone using the (very useful
IMO)
| >>extension of nested
101 - 200 of 1308 matches
Mail list logo
