Robert Dewar <[EMAIL PROTECTED]> writes:
| Florian Weimer wrote:
|
| > Probably it's hard to accept for hard-code C coders that a program
| > which generates correct machine code with all GCC versions released so
| > far (modulo bugs in GCC) can still be illegal C and exhibit undefined
| > behavi
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| >for (int i = min; i < max; ++i)
| >
| > and i, min and max don't change in the body, no matter what you think
| > of C's general "for" not being a FOR loop, the above is
Joe Buck <[EMAIL PROTECTED]> writes:
| On Sat, Jul 02, 2005 at 07:15:17PM -0400, Robert Dewar wrote:
| > Gabriel Dos Reis wrote:
| > >
| > > for (int i = min; i < max; ++i)
| > >
| > >
| > >and i, min and max don't change in the body, no
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| > The issue is whether they need to become expect in red herring or just
| > know how to write good and correct programs. Interestingly, backis
| > the old days K&R put emphasis on how to write good and useful programs
| > rather than academic exe
h is implemented in a very bad way.
|it casts double to size_t, which of course does a very poor job on big
|values (is the result of 1.0e100 cast to size_t defined ?).
|
| Michael
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Michael Veksler <[EMAIL PROTECTED]> writes:
[...]
| > 2. You don't know the answer. In that case you are supposed to file
| > a PR and trust bug-masters and maintainers about the issue.
| >
| > > std::tr1::hash is implemented in a very bad way.
| > > it casts double to size_t, which of co
Hi Michael,
PJP agreed on my forwarding his answers to the issue you raised.
--- Begin Message ---
To: C++ libraries mailing list
Message c++std-lib-15219
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Gabriel Dos Reis
> Sent:
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Michael Veksler wrote:
|
| > std::tr1::hash is implemented in a very bad way.
| > it casts double to size_t, which of course does a very poor job on big
| > values (is the result of 1.0e100 cast to size_t defined ?).
| >
| >
| A possible solutio
Joe Buck <[EMAIL PROTECTED]> writes:
| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| > It is definitely a good thing to use the full bits of value
| > representation if we ever want to make all "interesting" bits part of
| > the hash value
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Joe Buck <[EMAIL PROTECTED]> writes:
| >
| >| On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| >| > It is definitely a good thing to use the full bits of value
| >| >
Michael Veksler <[EMAIL PROTECTED]> writes:
| Joe Buck <[EMAIL PROTECTED]> wrote on 05/07/2005 21:10:25:
|
| > On Tue, Jul 05, 2005 at 08:05:39PM +0200, Gabriel Dos Reis wrote:
| > > It is definitely a good thing to use the full bits of value
| > > representation
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >If you regard the object representation as an array of bytes, does it
| >take long realize it is not much different from hashing a character
| >string?
| >
| It takes less if your proposal comes together w
Michael Veksler <[EMAIL PROTECTED]> writes:
| There is one more thing to consider: the ABI.
| By changing the code in the header file will break the ABI
| of tr1::unordered_set. Code compiled with older gcc and
| newer and fixed-gcc will not interoperate.
tr1 is very experimental and we don't gua
Avi Kivity <[EMAIL PROTECTED]> writes:
| On Tue, 2005-07-05 at 20:05 +0200, Gabriel Dos Reis wrote:
| > Paolo Carlin
| > It is definitely a good thing to use the full bits of value
| > representation if we ever want to make all "interesting" bits part of
| > the ha
Avi Kivity <[EMAIL PROTECTED]> writes:
| On Wed, 2005-07-06 at 15:54 +0300, Michael Veksler wrote:
|
| > > most architectures have different bit representations for +0.0 and -0.0,
| > > yet the two values compare equal.
| > >
| >
| > Yet, their sign bit is observable through things like
| >
Hi,
Is it true that nobody wanted to approved GCC-3.3.6 release announcement? :-/
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Texas A&M University -- Computer Science Depart
On Fri, 8 Jul 2005, Gerald Pfeifer wrote:
| On Fri, 8 Jul 2005, Gabriel Dos Reis wrote:
| > Is it true that nobody wanted to approved GCC-3.3.6 release
| > announcement? :-/
|
| I believe Jeff Law and Mark Mitchell are the two list admins with
| approval rights; it might be a good i
Jhair Tocancipa Triana <[EMAIL PROTECTED]> writes:
| Consider the following snippet:
|
| --8<---cut here---start->8---
| namespace foo
| {
| class A
| {
| friend class B;
|
| void bar (B);
| };
|
| class B {};
| }
| --8<---cut here
ved outside GCC main docuementation sources.
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Daniel Berlin <[EMAIL PROTECTED]> writes:
| Sorry for the tone, i've had a frustrating day for other reasons :)
|
| However, my real point still stands:
|
| 1. Every developer i've talked to who wants to work on gcc finds our
| current docs not useful, both the wwwdocs and the texinfo ones. Not
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-07-10 at 20:14 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | On Sun, 2005-07-10 at 19:31 +0200, Gerald Pfeifer wrote:
| > | > I noticed that the Wiki is getting more and
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| These are all related causes of the effect that our documentation and
| the process behind it hasn't worked for as long as i've been hacking gcc
| (5 or 6 years now). Everyone seems to pretend "oh, it's just the damn
| lazy developers fault, they
David Edelsohn <[EMAIL PROTECTED]> writes:
| >>>>> Gabriel Dos Reis writes:
|
| Gaby> That is a question I would have loved answered did I endorse its
| Gaby> predicate.
|
| Then by all means continue to use the existing docs in your world
| and le
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > However, I just don't have the bandwidth to dig through Wiki and port
| > things over, and it's not exactly an efficient nor motivating modus
| > operandi either.
| I would submit them from the wiki if i felt people found more use for it
| in
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| > 3. We should seriously consider writing and maintaining different guides
| > and references than the ones we have.
|
| Nobody won't object to that, I guess.
Indeed.
-- Gaby
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > Also, a web-browser is much slower than an info-browser, especially when
doing searchs.
|
| You must be close to the only user i've met who uses the info browser :)
Ahem; is your world that small?
-- Gaby
Steven Bosscher <[EMAIL PROTECTED]> writes:
| On Monday 11 July 2005 23:34, Gerald Pfeifer wrote:
| > On Mon, 11 Jul 2005, Giovanni Bajo wrote:
| > >> Perhaps the wiki could automatically send all changes to gcc-patches to
| > >> assist in review?
| > >
| > > I strongly support this (and was going
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Mon, 11 Jul 2005, Nicholas Nethercote wrote:
|
| > On Mon, 11 Jul 2005, Daniel Berlin wrote:
| >
| >>> Also, a web-browser is much slower than an info-browser,
| >>> especially when doing searchs.
| >> You must be close to the only user i've met who
Steven Bosscher <[EMAIL PROTECTED]> writes:
| On Tuesday 12 July 2005 00:06, Gabriel Dos Reis wrote:
| > Steven Bosscher <[EMAIL PROTECTED]> writes:
| > | Another idea that was coined on IRC is to have reviewing and commit
| > | after approval rules for the user manual, bu
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
| On Mon, 11 Jul 2005, Steven Bosscher wrote:
|
| > Another idea that was coined on IRC is to have reviewing and commit
| > after approval rules for the user manual, but to allow patches to the
| > internals manual in without review. Is that somethin
s.
|
| -- Pinski
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-07-16 at 12:50 -0400, D. Hugh Redelmeier wrote:
| > Sorry for the very late response. It is actually triggered by the
| > bugzilla entry
| > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
| >
| > The motivating example, abstracted f
Daniel Berlin <[EMAIL PROTECTED]> writes:
| >> object volatile).
| >
| > I don't understand your point. given
| > void Foo (char const * a) { *(char *)a = 5; }
| > the compiler generates code to store 5 through the pointer 'a'. It doesn't
turn
| > this into a call to 'abort', because it thin
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
[...]
| - let's not talk about "restrict"
Oh, it was getting fun :-)
-- Gaby
Dale Johannesen <[EMAIL PROTECTED]> writes:
| > the type of an object
| > changes depending on how it is accessed.
|
| this also makes nonsense of gcc's implementation of type-based aliasing
| rules.
|
|*((int *)&x) = 3
No. That one is specifically covered by the C and C++ standards
(alt
Maurizio Monge <[EMAIL PROTECTED]> writes:
| Hello,
| sorry for bothering you, but i wasn't able to find on the web
| the informations i was looking for about the cxx reflection branch
| and i wasn't albe to contact the mantainer (and i don't have enough
| knowlegde of gcc to deduce it from sourc
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > | There is no point in type qualifiers if they can be simply changed at
| > | will. Do not lie about your objects, and you will not be screwed over.
| >
| > only if the language you're implementing the compiler for says so, no
| > matter what nifty t
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > Daniel Berlin wrote:
| > >>> object volatile).
| > >>
| > >>
| > >> I don't understand your point. given
| > >> void Foo (char const * a) { *(char *)a = 5; }
| > >> the compiler generates c
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sat, 2005-07-16 at 23:28 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | On Sat, 2005-07-16 at 19:35 +0100, Nathan Sidwell wrote:
| > | > Daniel Berlin wrote:
| > | > >>
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| You make it sound like the standard is crystal clear on this issue, and
| everyone who disagrees with your viewpoint are just slimeballs trying to
| get around the clear wording of the standard.
I think you're profondly mistaken in your understa
Daniel Berlin <[EMAIL PROTECTED]> writes:
| We both know that standards committees are not made up of 1 or 2 people,
| and saying "people who designed and wrote the standard offer their view
| and interpretation of of they wrote " is not useful when they do not
| actually speak for the committee.
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > [...]
| >
| > | You make it sound like the standard is crystal clear on this issue, and
| > | everyone who
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
| | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
|
| | The way I see it is that people who designed and wrote the standard
| | offer their view and interpretation of of they wrote and some people
| | are determine
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
| | From: Gabriel Dos Reis <[EMAIL PROTECTED]>
|
| | After many exchanges via private mails and
| | looking at the various reports related to this issue, it has become
| | clear to me that the interpretations offered
Daniel Berlin <[EMAIL PROTECTED]> writes:
| Anything it sees anything in a statement with volatile, it marks the
| statement as volatile, which should stop things from touching it
| (anything that *does* optimize something marked volatile is buggy).
great!
| I should note that this will probably
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > I think that is urgent.
| No offense, but everyone thinks the problems that affect them are the
| most urgent.
miscompilation of KDE was declared urgent; I hope bug affecting code
semantics for X is not just "request for enhancement".
-- Gaby
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
[...]
| If GCC4 causes this much problem with X, I wonder what GCC4 will do to
| the Linux kernel. I understand that Linus generally prefers older
| GCCs to newer ones. It would be great if his preference were only
| superstition.
I do not follo
Michael Veksler <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
|
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | Anything it sees anything in a statement with volatile, it marks the
| > | statement as volatile, which should stop
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jul 16, 2005, at 11:07 PM, Gabriel Dos Reis wrote:
|
| > | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20222
| >
| >Andrew Pinski has declared this to be a bug, but the audit trail
| >isn't clear as to why.
|
| Becaus
"D. Hugh Redelmeier" <[EMAIL PROTECTED]> writes:
[...]
| | At this point we need:
| | (1) agreement from C and C++ maintainers on access through volatile
| | lvalue
|
| I don't know C++ well enough to say whether the analogous optimization
| is wrong for C++.
C++ has resisted, for two
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| You know, the more this goes on the more I believe we should send
| X3J11 a request for clarification. Perhaps X3J11 has been disbanded,
| so there may be problems. But we should ask.
I don't know whether X3J11 is disbanded. However, at the las
Richard Henderson <[EMAIL PROTECTED]> writes:
| On Sun, Jul 17, 2005 at 05:03:55PM +0100, Nathan Sidwell wrote:
| > Issue 1.
| > void Foo (char *ptr) {
| > *(volatile char *)ptr;
| > }
| ...
| > char c;
| > *(volatile char *)&c; // can this read be deleted?
| ...
| > void Foo (volatile char *ptr
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Note that I'm explicitly not taking a position on what the standard says.
| > The standard is notoriously incomplete with respect to object model issues,
| > including volatility, so I think that trying particularly hard to parse its
| > words in this ar
Paul Schlie <[EMAIL PROTECTED]> writes:
[...]
| > | With all due respect, unless there is an explicit reference in the
standard
| > | to contradict it's clearly stated requirement that an object's qualified
| > | lvalue ("locator value") designates the object being referenced, all
| > | interpr
Paul Schlie <[EMAIL PROTECTED]> writes:
| > From: Paul Schlie <[EMAIL PROTECTED]>
| >> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
| >> I don't understand what you mean here. Are you seriously suggesting
| >> that
| >>
| >> int main(
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| On Sat, 16 Jul 2005, Gabriel Dos Reis wrote:
| > No, I have no such plan. (And the branch has seen no much development
| > recently)
|
| But you still plan on working on it later?
Yes, we do.
| Do you think cvs.html
| could be updated
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Furthermore, 9.3.1/3 is at odds with 3.9.3/1, which says:
|
|Each type which is a cv-unqualified complete or
|incomplete object type or is void (_basic.types_) has three corre-
|sponding cv-qualified versions of its type: a const-qua
Mike Stump <[EMAIL PROTECTED]> writes:
| On Jul 17, 2005, at 4:48 AM, Gabriel Dos Reis wrote:
| > C++ has resisted, for two decades, the temptation of "improving" the
| > meaning of volatile :-) considering that it is C's baby.
|
| Do you know what the semantics of:
Daniel Berlin <[EMAIL PROTECTED]> writes:
| If you don't plan on using it for a while, you may be better off just
| taking a diff against the branchpoint exclude the branch from the
| conversion (which is about a month or so away), and recreate it after
| the move.
I have no plan of committing an
[EMAIL PROTECTED] (Kai Henningsen) writes:
| [EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 17.07.05 in <[EMAIL
PROTECTED]>:
|
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | On Sun, 2005-07-17 at 00:05 +0200, Gabriel Dos Reis wrote:
| > | > Daniel Berlin
Paul Schlie <[EMAIL PROTECTED]> writes:
| > Gabriel Dos Reis writes:
| > If by analysis, you can determine ...
|
| The problem with this type of logic is that it leads to arbitrary
| inconsistent designation of an object's reference as a function of
| the breadth of the &quo
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Jason Merrill wrote:
| > I think that the underlying problem here, as with pointers to data members,
| > comes from using POINTER_TYPE in the first type. Pointers to members are
| > not pointers, and so using POINTER_TYPE just causes confusion.
|
| I h
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > | the object-representation side; we need a PTRMEM_TYPE on the type side
| > | as well. Because we don't have a proper lowering phase, the
| > | difficulty is that we need to transmute PTRMEM_TYPE in
"Giovanni Bajo" <[EMAIL PROTECTED]> writes:
| Ebke, Hans-Christian <[EMAIL PROTECTED]> wrote:
|
| > I have to write this in Outlook, so I don't even try to get the quoting
| > right. Sorry. :-(
|
| http://jump.to/outlook-quotefix
|
| > But it would break applications relying on the old format
Geoff Keating <[EMAIL PROTECTED]> writes:
| On 22/07/2005, at 4:33 PM, Ian Lance Taylor wrote:
|
| > Geoffrey Keating <[EMAIL PROTECTED]> writes:
| >
| >> Although I can see that this is how you might think about the
| >> semantics of 'const' and 'volatile', I don't think they're an exact
| >> ma
Hi Dan,
Commands for querying open bugs for a specific target (say 3.4.5) of
a product do not seem to exist. The documentation for "index" says
index
But what I'm looking for is something like
index
probably augmented with "known-to-fail" or "known-to-work". But the
pressing
Daniel Berlin <[EMAIL PROTECTED]> writes:
| > But what I'm looking for is something like
| >
| > index
| >
| > probably augmented with "known-to-fail" or "known-to-work". But the
| > pressing need for me is the ability to specify the target.
|
|
| I just added this form.
| Give it a tr
Daniel Berlin <[EMAIL PROTECTED]> writes:
| Fixed now
Indeed. works now.
It would be great if bugzilla could send a notice back when it decides
to ignore commands :-)
| Sorry about that.
No problem. Thanks for the quick fix!
-- Gaby
Daniel Berlin <[EMAIL PROTECTED]> writes:
| On Sun, 2005-07-24 at 22:06 +0200, Gabriel Dos Reis wrote:
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | Fixed now
| >
| > Indeed. works now.
| > It would be great if bugzilla could send a notice back when it
Daniel Berlin <[EMAIL PROTECTED]> writes:
| Done on both counts.
Great!
Thanks,
-- Gaby
Haren Visavadia <[EMAIL PROTECTED]> writes:
| --- Kean Johnston wrote:
| > > The GCC team has been urged to drop support for
| > SCO
| > > Unix from GCC, as a protest against SCO's
| > irresponsible
| > > aggression against free software and GNU/Linux.
| > > We have decided to take no action at
nslation: 1
21768 ICE in error message due to violation of coding conventions
tree-optimization: 2
13000 Using -O2 cannot detect missing return statement in a function
20076 __builtin_return(__builtin_apply()) inlined incorrectly
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| Installed. If you prefer a different summary (I haven't changed the
| existing one), please let me know.
That is fine. Thanks!
-- Gaby
Mike Stump <[EMAIL PROTECTED]> writes:
| On Monday, July 25, 2005, at 01:58 AM, Paolo Carlini wrote:
| > By the way, since we have to point out that *so often*, maybe there is
| > something wrong on our part: I wonder whether changing the names of
| > those lists would help!?!? I don't know: gcc-d
Daniel Berlin <[EMAIL PROTECTED]> writes:
| Fixed.
| It was counting a slightly higher number of bugs than it actually sent
| (it does some of the query filtering client-side in the script)
Thanks.
-- Gaby
Kean Johnston <[EMAIL PROTECTED]> writes:
| > The full list of bugs is produced below. Maintainers, please look
| > into any of those and see which ones you can fix or give guidance for
| > fixes in ways that are suitable for a stable branch.
| Do I still have time / opportunity to refresh the SC
Kean Johnston <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Kean Johnston <[EMAIL PROTECTED]> writes:
| > | > The full list of bugs is produced below. Maintainers, please
| > look
| > | > into any of those and see which ones you can fix or give guidance
Kean Johnston <[EMAIL PROTECTED]> writes:
| > Here is how Mark and I have agreed on those sort of things. If such a
| > patch is accepted in 3.4.x but not in 4.0.x, then we've introduced a
| > regression in 4.0.x. So, the way we deal with it is that, the patch
| > is first applied to
| > 4.0.x, t
Mike Stump <[EMAIL PROTECTED]> writes:
| We are seeing tons of regressions (9 of 2377 for fink, over 100 or so
| out of 8000 was it for internal projects) in the build state of
| projects with code like:
|
| class bar {
|friend class foo;
|void baz(foo *x) {}
| };
|
| fro
Bernardo Innocenti <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > The full list of bugs is produced below. Maintainers, please look
| > into any of those and see which ones you can fix or give guidance for
| > fixes in ways that are suitable for a stable branch.
Kean Johnston <[EMAIL PROTECTED]> writes:
[...]
| However, I *think* I like the semantics of 'extern inline'
| better: use the inline version for the most part but if,
| for example, you take the address of the function, use the
| actual symbol stat(). But I see that most other fixincs
| use stat
Kean Johnston <[EMAIL PROTECTED]> writes:
| > [ cough ] "always_inline" [ cough ]
| HA!
|
| I *knew* there was a solution. Thank you Mike.
|
| So now I guess the question remains, for the cases where
| you want a function to behave differently depending on
| pre-processor conditionals, whats the
[EMAIL PROTECTED] writes:
[...]
| index
|
| Send list of open bugs in product , component .
| You can use '*' for components, which returns all of the open bugs in
| every component for that product.
Hi Dan,
Now that "index" has been enhanced to accept target version, w
nnot detect missing return statement in a function
20076 __builtin_return(__builtin_apply()) inlined incorrectly
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Hi Jan,
Your patch to mainline
http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00388.html
to defer handling of local statics has caused a regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22034
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22583
http://gcc.gnu.org/bugzilla/s
Rainer Orth <[EMAIL PROTECTED]> writes:
[...]
| I'm using gccbug since it provides the complete template where I just need
| to fill in the beef of the report. All I care for is the ability to handle
| bugs completely by email.
Amen. And it is important that one has at least a good flexibility
Daniel Berlin <[EMAIL PROTECTED]> writes:
| AFAICT (at least according to mail logs, etc) you are the only user of
apparently, you've to count properly.
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Daniel Berlin <[EMAIL PROTECTED]> writes:
| >
| > | AFAICT (at least according to mail logs, etc) you are the only user of
| >
| > apparently, you've to count properly.
|
| gccbug is different from what you are using.
OK.
-- Gaby
of coding conventions
tree-optimization: 2
13000 Using -O2 cannot detect missing return statement in a function
20076 __builtin_return(__builtin_apply()) inlined incorrectly
Thanks,
--
Gabriel Dos Reis
[EMAIL PROTECTED]
Volker Reichelt <[EMAIL PROTECTED]> writes:
| Just to let you know (to avoid duplicate work):
|
| There are several C++ bugs assigned to Mark which he already
| fixed on mainline and the 4.0 branch. Since he's busy with 4.0/4.1
| regressions, I'll try to backport (at least some of) the patches
|
Hi,
While working on a project involing checking the internal (logic)
consistency of the C++ front-end, I came across the following code in
cp/parser.c:cp_parser_translation_unit():
while (true)
{
cp_parser_declaration_seq_opt (parser);
/* If there are no tokens left then all
Richard Guenther <[EMAIL PROTECTED]> writes:
| On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > I don't think we ever defined "valid GENERIC" that way.
| >
| > About a year ago, when we tried to define it, that's what we came up
| > with. If that isn't the definition, then what *is*?
Steven Bosscher <[EMAIL PROTECTED]> writes:
| On Tuesday 06 September 2005 15:05, Gabriel Dos Reis wrote:
| > Richard Guenther <[EMAIL PROTECTED]> writes:
| > | On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > | > I don't think we ev
[EMAIL PROTECTED] (Richard Kenner) writes:
| The whole point of the gimplifier is to avoid making too many restrictions on
| what are valid trees: it's GIMPLE where we want to make those restrictions.
| It seems very duplicative to me to say that the process of creating
| temporaries for certain e
Mike Stump <[EMAIL PROTECTED]> writes:
| On Sep 2, 2005, at 2:30 PM, Richard B. Kreckel wrote:
| > This lead to developer irritation because people expect that what
| > compiled with GCC x.y.z should still compile with GCC x.y.z+1.
|
| I'll echo the generalized request that we try and avoid tight
Mike Stump <[EMAIL PROTECTED]> writes:
| On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
| > wrong-code generation that was fixed.
|
| Customers validate their app and are `happy' with the code
| generation, so this appears to not be a real an issue.
I think we did have an op
Daniel Berlin <[EMAIL PROTECTED]> writes:
| >int main(void)
| >{
| > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
|
| What exactly is this code expected to do?
| Call one_raw_spinlock and then throw away the result?
yes, that is implied by C99 semantics.
-- Ga
Joe Buck <[EMAIL PROTECTED]> writes:
| To me, even a 1% performance hit to fix this would be excessive.
My opinion is that is an excessive statement.
-- Gaby
Joe Buck <[EMAIL PROTECTED]> writes:
| On Fri, Sep 16, 2005 at 08:58:12PM +0200, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| >
| > | To me, even a 1% performance hit to fix this would be excessive.
| >
| > My opinion is that is an excessive s
Rafael Ávila de Espíndola <[EMAIL PROTECTED]> writes:
| The attached patch fixes the following warnings
|
| ../../gcc/gcc/treelang/parse.y: In function yyparse:
| ../../gcc/gcc/treelang/parse.y:532: warning: too many arguments for format
| ../../gcc/gcc/treelang/parse.y:641: warning: conversion l
401 - 500 of 1308 matches
Mail list logo
