Marcin Dalecki <[EMAIL PROTECTED]> writes:
| Looking at the function expand_omp_parallel in omp-low.c I have found
| the following line of code:
|
|bsi_insert_after (&si, t, TSI_SAME_STMT);
|
| Shouldn't this bee
|
|bsi_insert_after (&si, t, BSI_SAME_STMT);
|
| instead?
The TSI_* and
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| On Tue, 24 Oct 2006, Robert Schwebel wrote:
| > I don't understand yet how the next steps for 4.2 will look like; will
| > there be further snapshots (ftp://gcc.gnu.org/pub/gcc/snapshots/) of the
| > 4.2 branch, or will the next snapshots be only for 4.
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| We do want to make it as easy as we can make it to allow non-gurus to
| build from source, because we'll get a lot more testing that way. That
| said, I agree that an automatic download is inappropriate.
|
| However, if we detect at configure time th
Paolo Bonzini <[EMAIL PROTECTED]> writes:
| Kenneth Zadeck wrote:
| > I think that it is time that we in the GCC community took some time to
| > address the problem of compiling very large functions in a somewhat
| > systematic manner.
|
| While I agree with you, I think that there are so many th
Paolo Bonzini <[EMAIL PROTECTED]> writes:
[...]
| Unlike the authors of other VM's, I have no problem writing code so
| that the *latest* version of GCC will do its best, instead of
| complaining that GCC compiles my code worse on every release. So, I
You gave some examples; those are not the o
Douglas Gregor <[EMAIL PROTECTED]> writes:
[...]
| What would it take to get canonical type nodes in GCC? Nathan has
| experimented with some pieces of it, and I have experimented with
| others. It will likely be a large effort, but the payoff will be
| worth it in the end. Is the GCC community i
[EMAIL PROTECTED] (Richard Kenner) writes:
| > typedef int foo;
| > typedef foo* foo_p;
| >
| > In a truly canonical type-node environment, "foo" would have the same
| > type node as "int" (so we couldn't produce the name "foo" in
| > diagnostics), and "foo_p" would have the same type
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
[...]
| In C, there are several other sources of intransitivity, such as
| incomplete array types (int[10] and int[5] both compatible with int[] but
I'm sure we can (and probably must) specical-case that.
| not with each other), unprototyped funct
[EMAIL PROTECTED] (Richard Kenner) writes:
| > Like when int and long have the same range on a platform?
| > The answer is they are different, even when they imply the same object
| > representation.
| >
| > The notion of unified type nodes is closer to syntax than semantics.
|
| I'm more than a
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 11/7/06, Mike Stump <[EMAIL PROTECTED]> wrote:
| > Anyway, in C++, the entire template mechanism was rife with building
| > up duplicates. I'd propose that this problem can (and should be
| > addressed) and that we can do it incrementally. Start wit
Benjamin Kosnik <[EMAIL PROTECTED]> writes:
[...]
| My suggestion, which I've not seen here before, is to allow end-users
| to configure this. I see the need for both kinds of behavior: people
| who want to see the "real type" of the thing that they are using, and
| people who need "shorthands" t
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] (Richard Kenner) writes:
|
| > > My conclusion at the end was, the best speed up possible, isn't to
| > > mess with the callers, but rather, to get types canonicalized, then
| > > all the work that comptypes would normally do, h
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 11/8/06, Mike Stump <[EMAIL PROTECTED]> wrote:
| > On Nov 7, 2006, at 7:13 PM, Doug Gregor wrote:
| > > Now, how much do we worry about the fact that we won't be printing
| > > typedef names
| >
| > The only potential language gotcha I can think of is
"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
| * Ian Lance Taylor <[EMAIL PROTECTED]> [061108 16:15]:
| > This assumes, of course, that we can build an equivalence set for
| > types. I think that we need to make that work in the middle-end, and
| > force the front-ends to conform. As someone e
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
[...]
| I meant something very simple: for every type, there is a
| TYPE_CANONICAL field. This is how you tell whether two types are
| equivalent:
| TYPE_CANONICAL (a) == TYPE_CANONICAL (b)
| That is what I mean when I saw one memory dereference a
"Doug Gregor" <[EMAIL PROTECTED]> writes:
[...]
| With concepts, there are cases where we end up creating two different
| type nodes that we later find out should have been the same type node.
| Here's an example:
|
| template
| where LessThanComparable && SameType
| const T& weird_min(con
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 10 Nov 2006 19:15:45 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Doug Gregor" <[EMAIL PROTECTED]> writes:
| > | With concepts, there are cases where we end up creating two different
| >
"Doug Gregor" <[EMAIL PROTECTED]> writes:
| On 08 Nov 2006 03:45:26 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > [EMAIL PROTECTED] (Richard Kenner) writes:
| >
| > | > Like when int and long have the same range on a platform?
| > | > The answ
"Doug Gregor" <[EMAIL PROTECTED]> writes:
[...]
| > | For instance, say we have built the types T* and
| > | U* before seeing that same-type constraint. Now, we also need
| > | TYPE_CANONICAL (T*) == TYPE_CANONICAL (U*).
| > | And TYPE_CANONICAL(LessThanComparable) ==
| > | TYPE_CANONICAL(LessTha
Mike Stump <[EMAIL PROTECTED]> writes:
| On Nov 9, 2006, at 11:09 PM, Ian Lance Taylor wrote:
| > I meant something very simple: for every type, there is a
| > TYPE_CANONICAL field. This is how you tell whether two types are
| > equivalent:
| > TYPE_CANONICAL (a) == TYPE_CANONICAL (b)
|
| Ah
Mark Mitchell <[EMAIL PROTECTED]> writes:
[...]
| Also, it appears to me that there is something missing from N1958: there
| is no discussion about what happens when you apply typeid to a lambda
| function, or otherwise use it in a context that requires type_info.
There still are some discussion
[EMAIL PROTECTED] writes:
| > There still are some discussions going on (it is not alsways feasable
| > to reflect all the discussions), especially with respect to callback,
| > default policy and the like.
| >
| [...]
|
| > There is the discussion on callbacks.
|
| Are these discussions public?
Roberto Bagnara <[EMAIL PROTECTED]> writes:
| $ cat p.cc
| char c[2] = "a";
| char d[2] = c;
| $ g++ -c p.cc
| p.cc:2: error: cannot convert char [2] to char [2] in initialization
A good diagnostic would speak of assignment, but I lost that battle
some time ago.
-- Gaby
Brendon Costa <[EMAIL PROTECTED]> writes:
| Hi all,
|
| I have just come across a small difference in the way the C an C++
| front ends handle anonymous struct types which is causing me some
| grief. In particular the following code:
|
| typedef struct
| {
| int b1;
| int b2;
| } Blah;
|
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Manuel López-Ibáñez wrote:
| > The message for the following error:
| >
| > enum e { E3 = 1 / 0 };
| >
| > is in C: error: enumerator value for 'E3' not integer constant
| > and in C++: error: enumerator value for 'E3' is not an integer constant
| >
Andrew Pinski <[EMAIL PROTECTED]> writes:
| > You can work around this by using union's of pointers of both non-const
| > and const types, but the reinterpret_cast solution would be more attractive.
| >
| > Thoughts?
|
| This has nothing to do with const vs non-const but rather
| a and a are tw
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > | > You can work around this by using union's of pointers of both non-const
| > | > and const types, but the reinterpret_cast solution would be more
attractive.
| > | >
| > | > Thoughts?
| > |
Andrew Haley <[EMAIL PROTECTED]> writes:
| Robert Dewar writes:
| > Andrew Haley wrote:
| >
| > > We've already defined `-fwrapv' for people who need nonstandard
| > > arithmetic.
| >
| > Nonstandard implies that the result does not conform with the standard,
|
| I don't think it does; it
Andrew Haley <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis writes:
| > Andrew Haley <[EMAIL PROTECTED]> writes:
| >
| > | Robert Dewar writes:
| > | > Andrew Haley wrote:
| > | >
| > | > > We've already defined `-fwrapv' fo
Paul Eggert <[EMAIL PROTECTED]> writes:
| "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
|
| > Encapsulate reliable overflow checks for the various
| > arithmetic operations and types in functions or macros in
| > gnulib (for long long multiply, in this case).
|
| That might be the best approach
Paul Brook <[EMAIL PROTECTED]> writes:
| > Compiler can optimize it any way it wants,
| > as long as result is the same as unoptimized one.
|
| We have an option for that. It's called -O0.
|
| Pretty much all optimization will change the behavior of your program. The
| important distinction is
"Dave Korn" <[EMAIL PROTECTED]> writes:
[...]
| > We (in a major, commercial application) ran into exactly this issue.
| > 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
| > (it is a barrier across which neither the compiler nor CPU will reorder
| > things). Failing that
Andrew Haley <[EMAIL PROTECTED]> writes:
[...]
| C is no longer a kind of high-level assembly laguage:
| it's defined by a standard, in terms of an abstract machine, and some
| operations are not well-defined.
that does not mean C is not a kind of high-level assembly language.
:-/
-- Gaby
Paul Eggert <[EMAIL PROTECTED]> writes:
| Ian Lance Taylor <[EMAIL PROTECTED]> writes:
|
| > We could disable VRP's assumptions about signed overflow. I don't
| > know what else we could do to fix this case. I don't even know how we
| > could issue a useful warning. Perhaps there is a way.
|
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:
| >
| > 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
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
"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
"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 th
"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
"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
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:
| >
| > 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
"Seongbae Park" <[EMAIL PROTECTED]> writes:
| 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 ver
Vincent Lefevre <[EMAIL PROTECTED]> writes:
[...]
| Shouldn't GCC provide an extension to obtain the maximum and minimum
| values of integer types?
GCC already does. I suspect you meant a _generic_ way a la numeric_limits?
That is doable.
-- Gaby
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
[...]
| I'd like to see a -Warning flag added to GCC to spot places where GCC does
| something potentially too aggressive. Having that would do two things, it
| would make it easier for maintainers to audit their code, and it would
| make it easier fo
[EMAIL PROTECTED] (Richard Kenner) writes:
| > Here's an example from the intprops module of gnulib.
|
| These are interesting case.
|
| Note that all the computations are constant-folded.
|
| And I think this points the fact that we can "have our cake and eat it too"
| in many cases. Everyt
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > [EMAIL PROTECTED] (Richard Kenner) writes:
| >
| > | > Here's an example from the intprops module of gnulib.
| > |
| > |
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Richard Guenther" <[EMAIL PROTECTED]> writes:
| >
| > | On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| > | <[
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > I have been looking into infer_loop_bounds_from_signedness() called
| > from infer_loop_bounds_from_undefined().
| > At some places, nowrap_type_p() is used but this function operates
| > only on types, so
Andrew Pinski <[EMAIL PROTECTED]> writes:
[...]
| Again, please don't this the default for Fortran as integer
| overflow has been undefined since at least 1977 so I don't think
| it is a good idea for GCC in general anyways as evidence of Fortran.
The -Wundefined I'm working on is for C and C++
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| By the way, does traditional C really assume this? Is
| it the case that the original K&R document guarantees
| wrapping, or is what you meant here "traditional C
| compilers". There is quite a difference!
K&R C leaves arithmetic overflow undefine
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > for this specific function (vrp_int_const_binop), I'm issuing a
| > warning inside the else-if branch that tests for the overflowed
| > result. I'm unclear why tha
Paul Eggert <[EMAIL PROTECTED]> writes:
| [EMAIL PROTECTED] (Richard Kenner) writes:
|
| > I found my copy of K&R (Second Edition)
|
| Robert Dewar <[EMAIL PROTECTED]> writes:
|
| > so in fact the new C standard has changed
| > nothing from a definitional point of view,
|
| Wait, though: K
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| though I vaguely
| recall some complaints that you couldn't build v7 Unix if your compiler
| generated integer overflow traps.
this matches what I've told recently by some people who worked at bell
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > > What would you suggest this function to do, based on your comments?
| >
| > I'm not familiar enough with VRP to answer at that level, but at a higher
| > level, what I'd advocate is that t
"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| Yes, I have some patches in the queue to clean this up (and add some
| more stuff to VRP).
Great!
-- Gaby
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gerald Pfeifer wrote:
| > On Sun, 31 Dec 2006, Robert Dewar wrote:
| >> If you do it in signed expecting wrapping, then the optimization
| >> destroys your code. Yes, it is technically your fault, but this
| >> business of telling users
| >>
| >> "sorry,
[EMAIL PROTECTED] (Richard Kenner) writes:
[...]
| > but from other evidence it's clear that common traditional practice assumes
| > wrapv semantics.
|
| "Common traditional C" was actually yet another language that was even more
| ill-defined because it included such things as structure assignm
[EMAIL PROTECTED] (Richard Kenner) writes:
| > And the idea that people were not used to thinking seriously about
| > language semantics is very odd, this book was published in 1978,
| > ten years after the algol-68 report, a year after the fortran
| > 77 standard, long after the COBOL 74 standard
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| In fact K&R is much stronger than you think in terms of providing
| a precise definition of the language. Too bad people did not read it.
|
| As I said earlier in this thread, people seem to think that the
| standards committee invented something
Paul Schlie <[EMAIL PROTECTED]> writes:
| Upon attempted careful reading of the standard's excerpts quoted by
| Gabriel Dos Reis per <http://gcc.gnu.org/ml/gcc/2006-12/msg00763.html>,
| it's not clear that GCC's current presumption of LIA-1 overflow semantics
| in absen
Paul Eggert <[EMAIL PROTECTED]> writes:
| > In that case, we should make the Autoconf change optional.
| > I'll propose a further patch along those lines.
|
| OK, here's that proposed patch to Autoconf. Also, this patch attempts
| to discuss the matter better in the documentation. The documenta
Bernd Schmidt <[EMAIL PROTECTED]> writes:
[...]
| >> You say you doubt it affects performance. Based on what? Facts
| >> please, not guesses and hand-waiving...
| > The burden of proof ought to be on the guys proposing -O2
| > optimizations that break longstanding code, not on the skeptics.
|
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
[...]
| I believe the best option is
| going to be to take an case by case approach to selecting which
| optimizations should be enabled by default, and which optimizations
| should not be done except via a special
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
|
| > I do hope your and Richard G's constructive search for middle ground
| > will find echoes within the middle-end maintainers.
|
| This seems likely, since Richard and I are
[EMAIL PROTECTED] (Richard Kenner) writes:
[...]
| > for (i = 1; i < m; ++i)
| > {
| > if (i > 0)
| > bar ();
| > }
|
| Of course, this is an example where either the programmer is doing something
| very silly or else is expecting overflow and depending on wrap semantics, so
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
| On Tue, 2 Jan 2007, Gabriel Dos Reis wrote:
| >|> for (i = 1; i < m; ++i)
| >|> {
| >|> if (i > 0)
| >|> bar ();
| >|> }
| >| Of course, this is an example where either the programmer i
Diego Novillo <[EMAIL PROTECTED]> writes:
| Mark Mitchell wrote on 01/01/07 14:46:
|
| > What a thread this has turned out to be.
| >
| Indeed.
|
| In general, I'm not too thrilled with the idea of disabling
| transformations for the sake of non-conforming code. However, I would
| not mind a -f
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > [EMAIL PROTECTED] (Richard Kenner) writes:
| >
| > >> >> Many portable C programs assume that signed integer overflow wraps
around
| > >> >> reliably using two's complement arithmetic.
| > >> >
| > >>
| > >> I was looking for an adjective that m
Paul Eggert <[EMAIL PROTECTED]> writes:
| Here are further patches I checked into the Autoconf documentation to
| reflect today's comments (some of which I received privately). Thanks
| to all of you. The trickiest bit was documenting one simple way to
| reliably detect overflow without converti
Joe Buck <[EMAIL PROTECTED]> writes:
| On Fri, Jan 05, 2007 at 07:26:27AM -0800, Ian Lance Taylor wrote:
| > David Edelsohn <[EMAIL PROTECTED]> writes:
| >
| > > Are 4.0 snapshots still necessary? I suspect they should be
| > > discontinued.
| >
| > 4.0 still seems to be regarded as an activ
Joe Buck <[EMAIL PROTECTED]> writes:
| On Fri, Jan 05, 2007 at 03:02:00PM -0500, Andrew Pinski wrote:
| > >
| > > [ omitting gcc-patches ]
| > >
| > > On Fri, 5 Jan 2007, Joe Buck wrote:
| > > > I'd like to see it closed. We have some bugs that are only open
| > > > because they are targeted fo
Chris Pickett <[EMAIL PROTECTED]> writes:
| Hi,
|
| For one reason or another, I have spent a fair amount of time reading
| and getting confused by the warnings documentation. This applies to
| the optimizations as well, but I thought I would start with the
| warnings. Today I sat down and creat
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| > I assume the -Wno-xxx that are set by default would be moved to the
| > "default" section?
| >
|
| No.
Why?
| Warnings that are not active by default are obviously disabled,
| there is no need to mention them.
I don't understand. Pl
Tom Tromey <[EMAIL PROTECTED]> writes:
| > "Chris" == Chris Pickett <[EMAIL PROTECTED]> writes:
|
| Chris> For one reason or another, I have spent a fair amount of time
| Chris> reading and getting confused by the warnings documentation.
|
| Chris> 3. Get rid of the -Wno-xxx option listings
Chris Pickett <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > "Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| > [...]
| > | > I assume the -Wno-xxx that are set by default would be moved to
| > the
| > | > "default" section?
|
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| On 10 Jan 2007 18:48:58 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > |
| > | It seems to me that the only reason for Winit-self to exists is that
| > | people try to silence the -Wuninitialized warnings
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jan 11, 2007 at 02:08:48AM +0100, Gabriel Dos Reis wrote:
| > I'm well aware of the history of "-Winit-self". The issue is more
| > subtile that you would like to make it appear. You would have to study
| > more car
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
| On 11 Jan 2007 02:08:48 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > I'm well aware of the history of "-Winit-self". The issue is more
| > subtile that you would like to make it appear. You
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jan 11, 2007 at 04:09:16AM +0100, Gabriel Dos Reis wrote:
| > The subtlety I'm refering to is not that "void* p = &p" is not well-defined,
| > but rather the fact that when we see
| >
| > T t = some-expressio
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Richard --
|
| The GCC SC has been discussing libgcc-math. RMS says that he will need
| to consider the issue, and that he has other things he wants to do
| first. So, I'm afraid that we can't give you a good timeline for a
| resolution of the questio
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Manuel López-Ibáñez wrote:
|
| >> Sorry, please disregard my message: I was inadvertently using an old
| >> compiler (2007-01-06)
| >
| > So now you are getting both warning messages?
|
| Definitely I'm getting both:
|
| warning.cc: In function 'int m
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| >Specifically, for PR 30465 "((T)1 << 31) - 1" is potentially undefined
| >when T is a 32-bit signed type, but well-defined if T is unsigned or
| >wider than 32-bits.
| >
| FYI: this specific issue arises from std::numeric_limits on
| x86-linux:
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Gerald,
|
| >I noticed that -Wconversion now issues warnings in libstdc++.
| >
| in a nutshell, what is happening is that a difference of two pointers
| is assigned to an unsigned variable. First blush, the warning seems to
| me a bit overzealous, bu
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Manuel,
|
| >> in a nutshell, what is happening is that a difference of two pointers is
| >> assigned to an unsigned variable. First blush, the warning seems to me a
| >> bit overzealous, but if we concur that this is what we *really* want for
| >> 4
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| Let's wait a bit more for other opinions, say one day or two, then I
| will start the actual work. As far as I can see, other compilers do
| not warn in such cases, and adding casts (*) isn't the cleanest
| practice in the world, thus my caution..
Andrew Haley <[EMAIL PROTECTED]> writes:
| Paolo Carlini writes:
| > Andrew Haley wrote:
| >
| > > > Ok, I believe you. However, isn't true that, in general, because the
| > > > sign of the result is implementation defined,
| > >
| > >The sign of the result of % is no longer (since C99) im
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Hi Gaby,
|
| >There is something that we knoq about the code, that the compiler
| >does not have: we expect a sequence denoted by its first and last
| >element, so that the difference is always positive. However, the
| >difference of pointers is define
Andrew Haley <[EMAIL PROTECTED]> writes:
| Paolo Carlini writes:
| > Andrew Haley wrote:
| >
| > > > Ok, I believe you. However, isn't true that, in general, because the
| > > > sign of the result is implementation defined,
| > >
| > >The sign of the result of % is no longer (since C99) im
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| I vote against adding Wconversion to Wall before 4.3 is branched.
We are not in voting mode yet :-)
-- Gaby
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| >My concern is for vectors whose size() exceeds
| > numeric_limits::max() -- even if we would like to
| > avoid the general discussion. My understanding -- and I would like
| > to hear of others' -- is that the
| >semantics description in the tab
Paolo Carlini <[EMAIL PROTECTED]> writes:
[...]
| In summary, for v3, one possibility could be combining the two
| quantities, consistently for all the containers, thus, essentially,
| compute container::max_size as min(allocator::max_size,
| numeric_limits::max) (all the computations modulo
| si
On Mon, 15 Jan 2007, Paolo Carlini wrote:
| About the library itself, I'm also concerned by the weakness of our
| pragma system_header vs templates, which makes the whole warning game
| always very dangerous...
The system_header pragma + template issue is separate, and I thought
it was resolved a
On Mon, 15 Jan 2007, Paolo Carlini wrote:
| Ian Lance Taylor wrote:
[...]
Thanks. That escaped me because those bits were contributed by
knowledgeable GCC contributors, so I trusted them :-)
|
| >One way to write this expression in a fully defined manner is:
| >(T)1 << 30) - 1) << 1) +
On Tue, 16 Jan 2007, Manuel López-Ibáñez wrote:
| So the warning turned out to be useful or still was it too noisy ?
It is still noisy.
The limit macro fixes does not magically turn off the signed -> unsigned
noise -- it fixed a warning about overflow.
I'll send a separate message for the signed
Andrew Haley <[EMAIL PROTECTED]> writes:
| Michael Veksler writes:
| > Roberto Bagnara wrote:
| > >
| > > Reading the thread "Autoconf manual's coverage of signed integer
| > > overflow & portability" I was horrified to discover about GCC's
| > > miscompilation of the remainder expression tha
Andrew Haley <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis writes:
| > Andrew Haley <[EMAIL PROTECTED]> writes:
| >
| > | Michael Veksler writes:
| > | > Roberto Bagnara wrote:
| > | > >
| > | > > Reading the thread "Autoconf manual
Andrew Haley <[EMAIL PROTECTED]> writes:
| Roberto Bagnara writes:
| > Andrew Haley wrote:
| > > Roberto Bagnara writes:
| > > >
| > > > Reading the thread "Autoconf manual's coverage of signed integer
| > > > overflow & portability" I was horrified to discover about GCC's
| > > > misco
1 - 100 of 1308 matches
Mail list logo
