--- Comment #8 from gdr at cs dot tamu dot edu 2006-05-23 21:58 ---
Subject: Re: __builtin_nanf("") doesn't return a _quiet_ nan on parisc
"dave at hiauly1 dot hia dot nrc dot ca" <[EMAIL PROTECTED]> writes:
| --- Comment #7 from dave at hiauly1 dot
--- Comment #5 from gdr at cs dot tamu dot edu 2006-01-10 17:13 ---
Subject: Re: fill_n, generate_n assume Size is modifiable
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| But now I've decided thats no good, as difference_type isn't desi
--- Comment #23 from gdr at cs dot tamu dot edu 2006-01-11 15:56 ---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| #define'ing try and catch is non-conforming.
You forgot to mentin that -fno-
--- Comment #25 from gdr at cs dot tamu dot edu 2006-01-11 16:41 ---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #24 from hhinnant at apple dot com 2006-01-11 16:10 ---
| (In repl
--- Comment #27 from gdr at cs dot tamu dot edu 2006-01-12 00:12 ---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| Or are our quality standards higher than that?
The way you solve this is neither t
--- Comment #28 from gdr at cs dot tamu dot edu 2006-01-12 00:12 ---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #26 from hhinnant at apple dot com 2006-01-11 18:02 ---
| (In repl
--- Comment #30 from gdr at cs dot tamu dot edu 2006-01-12 01:10 ---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #28)
| > Subject: Re: exception_defines.h #defines try/catch
--- Comment #31 from gdr at cs dot tamu dot edu 2006-01-12 01:15 ---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
[...]
| I'm simply pointing out that the effort could be improved.
| Obviously no
--- Comment #2 from gdr at cs dot tamu dot edu 2006-01-17 04:01 ---
Subject: Re: Request for warning for parser ambiguity of function declarations
and variable declarations with initializations
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Maybe i
--- Comment #4 from gdr at cs dot tamu dot edu 2006-01-17 21:11 ---
Subject: Re: New: "pure virtual" destructors accepted by GCC, but cause link
failure
"lloyd at randombit dot net" <[EMAIL PROTECTED]> writes:
| The following code:
|
| class A
|{
|
--- Comment #5 from gdr at cs dot tamu dot edu 2006-01-17 21:12 ---
Subject: Re: "pure virtual" destructors accepted by GCC, but cause link
failure
"lloyd at randombit dot net" <[EMAIL PROTECTED]> writes:
| Ah, I misread it, but the bug should stay open IMO
--- Comment #7 from gdr at cs dot tamu dot edu 2006-01-17 22:00 ---
Subject: Re: "pure virtual" destructors accepted by GCC, but cause link
failure
"lloyd at randombit dot net" <[EMAIL PROTECTED]> writes:
| I'm now not quite sure what purpose a pu
--- Comment #10 from gdr at cs dot tamu dot edu 2006-01-18 20:29 ---
Subject: Re: New: want optional warning for non-constant declarations that
could be constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| Declaring variables and parameters as constants
--- Comment #11 from gdr at cs dot tamu dot edu 2006-01-18 20:30 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| std::cout << static_cast(t) << std::endl;
| }
--- Comment #12 from gdr at cs dot tamu dot edu 2006-01-18 20:33 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| --- Comment #8 from sigra at home dot se
--- Comment #15 from gdr at cs dot tamu dot edu 2006-01-18 22:35 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| > It does not make any sense to require the compile
--- Comment #16 from gdr at cs dot tamu dot edu 2006-01-18 22:37 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| > Isn't this a task for lint-like tool? GCC is
--- Comment #18 from gdr at cs dot tamu dot edu 2006-01-19 00:09 ---
Subject: Re: want optional warning for non-constant declarations that could be
constant
"sigra at home dot se" <[EMAIL PROTECTED]> writes:
| There is some good advice at
that precisely prooves m
--- Comment #4 from gdr at cs dot tamu dot edu 2006-10-19 21:32 ---
Subject: Re: incorrect "
On Thu, 19 Oct 2006, pinskia at gcc dot gnu dot org wrote:
| I tried a simple testcase and variations on it (changing (T)(ok) to just ok
and
| such):
yes, the parens don't chang
--- Comment #7 from gdr at cs dot tamu dot edu 2006-10-19 21:57 ---
Subject: Re: diagnostic on correct code; regression from
3.4.4
On Thu, 19 Oct 2006, pinskia at gcc dot gnu dot org wrote:
| Reduced testcase:
Very nice.
| template< bool C > int assertion_failed( int);
| te
--- Comment #6 from gdr at cs dot tamu dot edu 2007-01-26 21:21 ---
Subject: Re: [4.3 regression] -Wreturn-type warns about more than what the
documentation says
"bangerth at math dot tamu dot edu" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.3 regression] -Wreturn-
--- Comment #7 from gdr at cs dot tamu dot edu 2007-01-26 21:32 ---
Subject: Re: [4.3 regression] -Wreturn-type warns about more than what the
documentation says
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| OK. That is fine. Just that I am new here and
--- Comment #9 from gdr at cs dot tamu dot edu 2007-01-28 04:11 ---
Subject: Re: When using 'or' keyword, the error message speaks of a '||' token
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Unless someone decides to fix the whole C
--- Comment #21 from gdr at cs dot tamu dot edu 2007-01-30 01:30 ---
Subject: Re: std::bad_alloc::what() does not explain what happened
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| What do you mean by "incorrect"?!? If you subclass, either you
| p
--- Comment #23 from gdr at cs dot tamu dot edu 2007-01-30 02:11 ---
Subject: Re: std::bad_alloc::what() does not explain what happened
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| --- Comment #22 from pcarlini at suse dot de 2007-01-30 01:42 --
--- Comment #25 from gdr at cs dot tamu dot edu 2007-01-30 03:53 ---
Subject: Re: std::bad_alloc::what() does not explain what happened
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| > However, the use of typeid is very convenient in the sense that we
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-31 06:43 ---
Subject: Re: DejaGNU does not distinguish between errors and warnings
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #8)
| > This is nice, Manuel, I hadn't
--- Comment #15 from gdr at cs dot tamu dot edu 2007-01-31 21:15 ---
Subject: Re: DejaGNU does not distinguish between errors and warnings
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #11)
| > The other DejaGnu procs that are
--- Comment #7 from gdr at cs dot tamu dot edu 2007-02-03 16:31 ---
Subject: Re: [4.0/4.1 regression] mips: unable to find a register to spill in
class 'FP_REGS'
"joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| >What|Remov
--- Comment #7 from gdr at cs dot tamu dot edu 2007-02-03 16:32 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] invalid parameter forward
declarations not diagnosed
"joseph at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Reg
--- Comment #19 from gdr at cs dot tamu dot edu 2007-02-03 16:34 ---
Subject: Re: [4.0/4.1 Regression] ICE in
ix86_secondary_memory_needed, at config/i386/i386.c:16446
On Sat, 3 Feb 2007, Joseph S. Myers wrote:
| On Sat, 3 Feb 2007, gdr at gcc dot gnu dot org wrote:
|
| > Fixed
--- Comment #1 from gdr at cs dot tamu dot edu 2007-02-08 10:16 ---
Subject: Re: New: name conflict between class and namespace name is not
recognized
"ulrich dot lauther at siemens dot com" <[EMAIL PROTECTED]> writes:
| 1 namespace Foo {
|2 };
|3
|
--- Comment #3 from gdr at cs dot tamu dot edu 2007-02-09 12:13 ---
Subject: Re: Bogus warning on argument passing discarding qualifiers
"gdr at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| This warning appears only when optimizing.
During interpro
--- Comment #4 from gdr at cs dot tamu dot edu 2007-02-19 19:48 ---
Subject: Re: Should warn about boolean constant false used in pointer context
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I don't see why we should warn about a very valid and
--- Comment #5 from gdr at cs dot tamu dot edu 2007-02-19 19:59 ---
Subject: Re: Should warn about boolean constant false used in pointer context
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| No, it is not. And I don't think it should be warned b
--- Comment #7 from gdr at cs dot tamu dot edu 2007-02-19 20:49 ---
Subject: Re: Should warn about boolean constant false used in pointer context
"mueller at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| there is an implicit value conversion, boolean "fal
--- Comment #1 from gdr at cs dot tamu dot edu 2007-02-27 15:17 ---
Subject: Re: New: Junk in diagnostic message
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Maybe this is a known issue, but I just noticed that many meaningless words
are
| output for th
--- Comment #17 from gdr at cs dot tamu dot edu 2007-03-07 21:35 ---
Subject: Re: bogus array overflow warnings in unrolled loops
"rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| This is why we have this bug -- because loop unrolling creates possibly
|
--- Comment #5 from gdr at cs dot tamu dot edu 2007-03-08 13:20 ---
Subject: Re: [4.3 Regression] warning: same canonical type node for different
types
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #3 from manu at gcc dot gnu dot org
--- Comment #2 from gdr at cs dot tamu dot edu 2007-03-16 15:15 ---
Subject: Re: New: [4.2 regression] extern declaration of variable in
anonymous namespace prevents use of its address as template argument
"zak at transversal dot com" <[EMAIL PROTECTED]> writes:
| Th
--- Comment #7 from gdr at cs dot tamu dot edu 2007-03-17 23:35 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Note, however, that, as far as I can see, such try/catch are *not* in th
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-19 12:40 ---
Subject: Re: std::valarray should be annotated with OpenMP directives
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
|
| Wolfgang: I agree. We should have also parallelized this for
--- Comment #10 from gdr at cs dot tamu dot edu 2007-03-19 15:19 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| And I think that we should not warn about generated code. No
--- Comment #5 from gdr at cs dot tamu dot edu 2007-03-19 15:23 ---
Subject: Re: std::valarray should be annotated with OpenMP directives
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #3)
| > I suspect that parallelizing for SSE/Al
--- Comment #12 from gdr at cs dot tamu dot edu 2007-03-19 22:45 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #10)
| >
| > I fully agree.
|
| I
--- Comment #16 from gdr at cs dot tamu dot edu 2007-03-19 23:40 ---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| But the user can see the code,
Andrew --
When you don'
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-22 15:29 ---
Subject: Re: #'typename_type' not supported by dump_decl#
"guillaume dot melquiond at ens-lyon dot fr" <[EMAIL PROTECTED]> writes:
| I just encountered another instance of a missing type
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-23 18:33 ---
Subject: Re: data members in multiple inheritance
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Maybe this is not obvious to me why this is valid code, why is this
| valid code?
--- Comment #59 from gdr at cs dot tamu dot edu 2007-03-28 17:43 ---
Subject: Re: __cplusplus defined to 1, should be 199711L
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Request to re-assign to me.
Please, go ahead :-)
-- Gaby
--
http://gcc.
--- Comment #62 from gdr at cs dot tamu dot edu 2007-03-28 17:54 ---
Subject: Re: __cplusplus defined to 1, should be 199711L
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #60 from bkoz at gcc dot gnu dot org 2007-03-28 17:48
-
--- Comment #15 from gdr at cs dot tamu dot edu 2007-03-29 16:43 ---
Subject: Re: Bug in template type in error message.
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| Still happens with a recent mainline snapshot.
This one is tricky. I once had a patch
--- Comment #7 from gdr at cs dot tamu dot edu 2007-04-08 21:53 ---
Subject: Re: /usr/include/c++/bits/cmath.tcc: no match for ternary
'operator?:' in '((__n % 2u) != 0u) ? __x : 1'
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Gaby, no
--- Comment #11 from gdr at cs dot tamu dot edu 2007-04-09 15:33 ---
Subject: Re: [4.3 Regression] Canonical types failures
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| Talking about canonical types: I think the idea of only issuing a warning
| in cases
--- Comment #6 from gdr at cs dot tamu dot edu 2007-07-14 13:02 ---
Subject: Re: Request for new warning: useless dynamic_casts
"lloyd at randombit dot net" <[EMAIL PROTECTED]> writes:
| I think that's a good definition. My impression is that dynamic_cast is
fair
--- Comment #2 from gdr at cs dot tamu dot edu 2007-07-18 16:02 ---
Subject: Re: GCC (SVN) naive build fails due to use of '%I64d'
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Anyways the work around is to
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-04 13:01 ---
Subject: Re: New: add checking for array new & delete
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| Given the following C++ code
|
| class K
| {
| public:
| void f
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-04 22:06 ---
Subject: Re: add checking for array new & delete
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| The compiler can generate a whole bunch of warnings
| already.
Which fall in different
--- Comment #4 from gdr at cs dot tamu dot edu 2007-08-04 22:09 ---
Subject: Re: add checking for array new & delete
"dcb314 at hotmail dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #1)
| > Special, dedicated tools exist for that task.
|
|
--- Comment #7 from gdr at cs dot tamu dot edu 2007-08-18 19:52 ---
Subject: Re: C++ error on valid code: has incomplete type
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| Thanks for the explanation. That is new to me.
Check for "abomination" in D&
--- Comment #21 from gdr at cs dot tamu dot edu 2007-08-20 18:50 ---
Subject: Re: warn for uninitialized arrays passed as const* arguments
"manu at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| When I say "constant are not propagated" I mean "the
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-20 18:57 ---
Subject: Re: New: C++ frontend should not warn about new a[0] in template
context
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| For this simplified code:
|
| template
| char* f1() { if (c == 0
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-20 23:23 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
"mec at google dot com" <[EMAIL PROTECTED]> writes:
| "new T[0]" looks like defined behavior to me.
|
| [expr
--- Comment #5 from gdr at cs dot tamu dot edu 2007-08-21 00:19 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| The problem I see is that this unconditional warning warns abo
--- Comment #1 from gdr at cs dot tamu dot edu 2007-08-21 00:23 ---
Subject: Re: New: C++ frontend finds static function in argument dependent
lookup based on template parameter
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| In the C++ standard
--- Comment #15 from gdr at cs dot tamu dot edu 2007-08-21 20:27 ---
Subject: Re: Awful error messages with virtual functions
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The pointer_plus_exprt stuff has been fixed.
|
| We are now back to err
--- Comment #40 from gdr at cs dot tamu dot edu 2007-08-29 13:19 ---
Subject: Re: Unnecessary anonymous namespace warnings
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
| On 29 Aug 2007 03:15:04 -, bangerth at dealii dot org
| <[EMAIL PROTECTED]> wrote:
| >
--- Comment #3 from gdr at cs dot tamu dot edu 2007-08-30 23:43 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 30 Aug 2007, pinskia at gcc dot gnu dot org wrote:
| I think it is wrong to warn for unused typedefs, they are all over headers.
In general, I tend to
--- Comment #5 from gdr at cs dot tamu dot edu 2007-08-30 23:51 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 30 Aug 2007, pcarlini at suse dot de wrote:
|
|
| --- Comment #4 from pcarlini at suse dot de 2007-08-30 23:46 ---
| (In reply to comment #3)
--- Comment #7 from gdr at cs dot tamu dot edu 2007-08-31 00:05 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 30 Aug 2007, pcarlini at suse dot de wrote:
| Well, assuming there are no "no-go" theorems about that problem ;) I would be
| certainly intere
--- Comment #9 from gdr at cs dot tamu dot edu 2007-08-31 01:03 ---
Subject: Re: A warning for "unused" typedefs?
On Thu, 31 Aug 2007, fang at csl dot cornell dot edu wrote:
| Aren't unused typedefs sometimes useful for static assertions and concept
| checking,
--- Comment #4 from gdr at cs dot tamu dot edu 2007-09-01 21:07 ---
Subject: Re: Broken diagnostic: 'component_ref' not supported by dump_decl
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| But do we really want 'a.A::b' ?!?
No, we don&
--- Comment #8 from gdr at cs dot tamu dot edu 2007-09-01 21:59 ---
Subject: Re: Broken diagnostic: 'component_ref' not supported by dump_decl
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Another testcase:
| void f(bool *b)
| {
| (*b)--
--- Comment #7 from gdr at cs dot tamu dot edu 2007-09-08 20:00 ---
Subject: Re: C++ frontend should not warn about new a[0] in template context
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Hi. So, what shall we do here? I can remove the warni
--- Comment #2 from gdr at cs dot tamu dot edu 2007-09-30 21:22 ---
Subject: Re: configuration failure during native build
"rask at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #1 from rask at gcc dot gnu dot org 2007-09-30 20:35 ---
| Ple
--- Comment #13 from gdr at cs dot tamu dot edu 2007-10-04 01:46 ---
Subject: Re: ICE when mangling template which uses typeof
"jason at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The testcase works fine if I change typeof to __decltype and add the
nece
--- Comment #4 from gdr at cs dot tamu dot edu 2007-10-04 20:29 ---
Subject: Re: configuration failure during native build
"dannysmith at users dot sourceforge dot net" <[EMAIL PROTECTED]>
writes:
| --- Comment #3 from dannysmith at users dot sourceforge dot net
--- Comment #9 from gdr at cs dot tamu dot edu 2007-10-12 16:19 ---
Subject: Re: initialization of non-integral member constant not rejected
"rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| We should also warn by default with -std=c++98 or -std=c++0x.
--- Comment #7 from gdr at cs dot tamu dot edu 2007-10-18 18:46 ---
Subject: Re: configuration failure during native build
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Yo Gaby. Has this been worked out? Can we close this?
As long as we document th
--- Comment #2 from gdr at cs dot tamu dot edu 2009-10-20 16:42 ---
Subject: Re: valarray_array.h seems to overuse __restrict__
"paolo dot carlini at oracle dot com" writes:
| I think this line, in general all the uses of __restrict__ in valarray are
| *very* old... Let
--- Comment #83 from gdr at cs dot tamu dot edu 2007-05-18 14:26 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| The test case in comment #71 doesn't use
--- Comment #84 from gdr at cs dot tamu dot edu 2007-05-18 14:30 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #81 from rguent
--- Comment #100 from gdr at cs dot tamu dot edu 2007-05-18 22:04 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| I'm not sure what to make of c
--- Comment #101 from gdr at cs dot tamu dot edu 2007-05-18 22:12 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| But I don't think that is the q
--- Comment #102 from gdr at cs dot tamu dot edu 2007-05-18 22:15 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| --- Comment #96 from pcarlini at s
--- Comment #103 from gdr at cs dot tamu dot edu 2007-05-18 22:16 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| --- Comment #98 from pcarlini at s
--- Comment #108 from gdr at cs dot tamu dot edu 2007-05-22 16:55 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.
--- Comment #110 from gdr at cs dot tamu dot edu 2007-05-22 17:25 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| > Indeed, consider this:
|
--- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| But, I
--- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.
--- Comment #117 from gdr at cs dot tamu dot edu 2007-05-22 18:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"dberlin at dberlin dot org" <[EMAIL PROTECTED]> writes:
[...]
| And if you've raised the
--- Comment #119 from gdr at cs dot tamu dot edu 2007-05-22 18:40 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.
--- Comment #121 from gdr at cs dot tamu dot edu 2007-05-22 20:12 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
[...]
| And, although I don't
--- Comment #123 from gdr at cs dot tamu dot edu 2007-05-22 20:53 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mrs at apple dot com" <[EMAIL PROTECTED]> writes:
| I think it is reasonable to push the ti
--- Comment #125 from gdr at cs dot tamu dot edu 2007-05-23 14:22 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"rguenther at suse dot de" <[EMAIL PROTECTED]> writes:
[...]
| But you can still perform h
--- Comment #129 from gdr at cs dot tamu dot edu 2007-05-23 15:59 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"rguenther at suse dot de" <[EMAIL PROTECTED]> writes:
| Note that it is important to retain t
--- Comment #147 from gdr at cs dot tamu dot edu 2007-05-23 23:42 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Of course, Gaby's memory mod
--- Comment #148 from gdr at cs dot tamu dot edu 2007-05-23 23:50 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Gaby's claim, as I understan
--- Comment #149 from gdr at cs dot tamu dot edu 2007-05-23 23:56 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #140 from mark at
--- Comment #150 from gdr at cs dot tamu dot edu 2007-05-23 23:57 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.
--- Comment #151 from gdr at cs dot tamu dot edu 2007-05-24 00:58 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"rguenther at suse dot de" <[EMAIL PROTECTED]> writes:
[...]
| > Gaby's model says
1 - 100 of 166 matches
Mail list logo
