--- Comment #3 from gdr at cs dot tamu dot edu 2010-05-22 15:32 ---
Subject: Re: [C++0x] std::complex vs. initialization lists
paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org writes:
| Jason, can you have a look to the errors due to the ambiguous overloading
| pointed
--- 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 gcc-bugzi...@gcc.gnu.org writes:
| I think this line, in general all the uses of __restrict__ in valarray are
| *very
--- Comment #13 from gdr at cs dot tamu dot edu 2008-06-09 14:06 ---
Subject: Re: A warning for unused typedefs?
paolo dot carlini at oracle dot com [EMAIL PROTECTED] writes:
| Hi Gaby, just a pointer, this is the enhancement PR I was talking about...
Many thanks, Paolo.
-- Gaby
--- Comment #32 from gdr at cs dot tamu dot edu 2008-01-07 08:00 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #31 from mark at codesourcery dot com 2008
--- Comment #33 from gdr at cs dot tamu dot edu 2008-01-07 08:10 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.2/4.3 regression] ICE with incompatible
--- Comment #35 from gdr at cs dot tamu dot edu 2008-01-08 02:52 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #34 from mark at codesourcery dot com 2008
--- Comment #23 from gdr at cs dot tamu dot edu 2008-01-06 15:28 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.2/4.3 regression] ICE with incompatible
--- Comment #25 from gdr at cs dot tamu dot edu 2008-01-07 00:38 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: [4.2/4.3 regression] ICE with incompatible
--- Comment #27 from gdr at cs dot tamu dot edu 2008-01-07 06:54 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #26 from mark at codesourcery dot com 2008
--- Comment #28 from gdr at cs dot tamu dot edu 2008-01-07 06:57 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| Imagine that you're a user. You read about GNU __complex__
--- Comment #29 from gdr at cs dot tamu dot edu 2008-01-07 07:09 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| We have no plan of how those new constructors will interact
--- Comment #20 from gdr at cs dot tamu dot edu 2008-01-05 07:51 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
mark at codesourcery dot com [EMAIL PROTECTED] writes:
| --- Comment #18 from mark at codesourcery dot com 2007
--- Comment #21 from gdr at cs dot tamu dot edu 2008-01-05 07:51 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with
complex type conversion
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Also, I'm afraid the implementation of parts of complex
--- Comment #3 from gdr at cs dot tamu dot edu 2007-11-08 11:23 ---
Subject: Re: warning in backward_warning.h is illegible
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| We cannot assume that people encountering the warning will have web access.
That is true
--- 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 that that build on MinGW
--- 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.
I agree that we
--- 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
2007-10-04 08:26
--- 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
necessary
| template template
--- 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 ---
| Please look in your
--- 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 warning completely or
| conditionalize
--- 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't. The format specific is OK -- e.g
--- 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)--;
| }
|
| And another one
--- 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 agree
--- 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)
| Maybe
--- 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 interested in studying
--- 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, using templates?
Maybe
--- 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:
| It is a good question in itself
--- 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 error messages like
--- 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 constant value of a
| variable
--- 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:
|
| templateint c
| char* f1() { if (c == 0) return 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.new] 5.3.4 -7-
| When the value
--- 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 about code which
is
| completely
--- 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 section 14.6.4.2 [temp.dep.candidate
--- Comment #7 from gdr at cs dot tamu dot edu 2007-08-18 19:52 ---
Subject: Re: C++ error on valid code: anonymous has incomplete type
ian at airs dot com [EMAIL PROTECTED] writes:
| Thanks for the explanation. That is new to me.
Check for abomination in DE :-)
| I am now going
--- 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();
| void g();
|
| private
--- 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 mindset that the one you
--- 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.
|
| Would you be willing to name
--- 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 configure with
| --disable
--- 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
fairly
| expensive,
well, I
--- Comment #3 from gdr at cs dot tamu dot edu 2007-06-02 20:28 ---
Subject: Re: Complex __float128 is rejected
joseph at codesourcery dot com [EMAIL PROTECTED] writes:
| Subject: Re: Complex __float128 is rejected
|
| On Sat, 2 Jun 2007, ubizjak at gmail dot com wrote
--- Comment #5 from gdr at cs dot tamu dot edu 2007-05-29 11:11 ---
Subject: Re: warning: deleting void* is undefined sometimes bogus
andrew dot stubbs at st dot com [EMAIL PROTECTED] writes:
| Well, obviously I'll let people who really understand the details of this
| decide whether
--- Comment #156 from gdr at cs dot tamu dot edu 2007-05-24 10:29 ---
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:
[...]
| I brought in the union example to point
--- Comment #158 from gdr at cs dot tamu dot edu 2007-05-24 10:47 ---
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:
[...]
| Now, if I understand your argument below correctly
--- 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 hoisting loads of incoming
--- 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 the capability
--- 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 model doesn't allow
--- 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 understand it, is that writing
--- 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 codesourcery dot com
--- 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.2/4.3 Regression] placement
--- 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 that we know less about dynamic
--- Comment #152 from gdr at cs dot tamu dot edu 2007-05-24 01:06 ---
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:
[...]
| However, I don't like this approach because I
--- 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.2/4.3 Regression] placement
--- 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:
|
| // tu-2.C
| void
--- 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 don't think the standard
--- 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.2/4.3 Regression] placement
--- 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 them now, can you please try
--- 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.2/4.3 Regression] placement
--- 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 have the time/energy
--- 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 tighening language
--- 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 placement new either
--- 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 rguenth at gcc dot gnu dot
--- 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 comment #84. We don't determine
--- 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 question at hand. The variable
--- 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 suse dot de 2007-05-18
--- 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 suse dot de 2007-05-18
--- 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 like the current one
--- 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, not a big deal (complext is unspecified
--- 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 #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.gnu.org/bugzilla
--- 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
---
|
| Mine.
|
| Current
--- 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?
paragrpah 10.2/2 from
--- Comment #3 from gdr at cs dot tamu dot edu 2007-03-22 15:29 ---
Subject: Re: #'typename_type' not supported by dump_decl#declaration error
guillaume dot melquiond at ens-lyon dot fr [EMAIL PROTECTED] writes:
| I just encountered another instance of a missing typename diagnostic
--- 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 SSE/Altivec a la
| MacSTL
--- 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 matter if it is
| generated
--- 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/Altivec might be more
--- 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 am not agreeing fully,
Well
--- 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't understand an issue, please
--- 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 the
| library code proper
--- 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:
| The following code
--- 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 2007-03-08 11:40
--- 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
| unreachable code
--- 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 this wrong snippet
--- 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 well defined
--- 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 by -Wconversion. After
| all
--- 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 false to address 0. I
think
--- 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 interprocedural analysis.
--
http
--- 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
|4 class Foo {
|5
--- 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|Removed |Added
--- 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 Regression] invalid parameter
--- 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 #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 wrapped in the GCC
--- 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 considered changing
--- 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
| provide your own what(), or you
--- 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 ---
| (In reply
--- 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
| have to defined what
--- 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++ parser error handling,
| this and PR
--- 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-type warns about
--- 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 I would like
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-17 11:09 ---
Subject: Re: [regression] -Wconversion triggers warnings for
deque::push_back()
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Gaby, any news about the signed - unsigned warning itself? Are we going to
| keep
--- Comment #21 from gdr at cs dot tamu dot edu 2007-01-17 13:47 ---
Subject: Re: unsigned warning in template
tromey at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The particularity of such expressions is that they are constants.
|
| I've thought about this a bit but I don't
1 - 100 of 165 matches
Mail list logo
