http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #12 from Gabriel Dos Reis ---
(In reply to Iain Sandoe from comment #10)
> also the gcc driver silently ignores -static-libstdc++.
Isn't this the problem?
> certainly, the -B options are passed when other gcc components are built (o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #9 from Gabriel Dos Reis ---
(In reply to Iain Sandoe from comment #8)
> note that the patch at:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01460.html
>
> is not quite enough to fix this on Darwin - since we use :
>
> %{stati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #7 from Gabriel Dos Reis ---
(In reply to Eric Botcazou from comment #4)
> > OK, I see the emitted reference to 'operator delete', and I suspect I
> > have an idea of why the compiler generated this reference even though
> > it isn't u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #6 from Gabriel Dos Reis ---
(In reply to Eric Botcazou from comment #4)
> > OK, I see the emitted reference to 'operator delete', and I suspect I
> > have an idea of why the compiler generated this reference even though
> > it isn't u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #5 from Gabriel Dos Reis ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Gabriel Dos Reis from comment #2)
> > OK, I see the emitted reference to 'operator delete', and I suspect I
> > have an idea of why the compiler ge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #2 from Gabriel Dos Reis ---
OK, I see the emitted reference to 'operator delete', and I suspect I
have an idea of why the compiler generated this reference even though
it isn't used anywhere in the input source code.
Why are we linki
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #1 from Gabriel Dos Reis ---
Here is the definition of pretty_printer::~pretty_printer ()
at the location indicated:
pretty_printer::~pretty_printer ()
{
buffer->~output_buffer ();
XDELETE (buffer);
}
The macro XDELETE is define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #3 from Gabriel Dos Reis ---
Also, there might be some interactions with move semantics; I don't know.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997
--- Comment #2 from Gabriel Dos Reis ---
(In reply to Paolo Carlini from comment #1)
> Gaby, can you help me with this?
I think this is typical confusion about what valarray expressions are.
f1() has some complicated return type that has essenti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #11 from Gabriel Dos Reis ---
(In reply to Paolo Carlini from comment #10)
> Gaby, do you have an opinion on this? Irrespective of the long double issue,
> do you want me to re-enable (contra LWG 844) the pow(const complex<>&, int)
> o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #30 from Gabriel Dos Reis ---
(In reply to Paolo Carlini from comment #27)
> DR2058 is now WP, thus we are supposed to reassess this. Now, according to
> the resolution, additional 'begin' and 'end' overloads shall *not* be added,
> th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582
--- Comment #10 from Gabriel Dos Reis 2013-04-23
03:45:56 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Printing int[] or int[size_t] would be confusing too.
>
> More confusing than int[(((sizetype)) + 1)] ?
>
> What about?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11582
--- Comment #8 from Gabriel Dos Reis 2013-04-22
10:10:36 UTC ---
(In reply to comment #7)
> The '[(((sizetype)) + 1)]' is just awful. If we don't know the
> actual type there, that is "int [size()]", then we should just print 'int []'
> o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401
Gabriel Dos Reis changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54401
Bug #: 54401
Summary: Missing diagnostics about type-alias at class scope
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52863
Bug #: 52863
Summary: Enable -Wall by default
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #18 from Gabriel Dos Reis 2011-11-02
12:48:47 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> retu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #17 from Gabriel Dos Reis 2011-11-02
12:48:23 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> retu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #14 from Gabriel Dos Reis 2011-11-02
12:27:20 UTC ---
(In reply to comment #9)
> Created attachment 25654 [details]
> BC2
Since we are talking about branch cut and prespectiving
since zeros, I think we should avoid the
the arithmeti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48365
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #25 from Gabriel Dos Reis 2011-06-14
14:01:30 UTC ---
(In reply to comment #23)
> Ok, now I see, it's the operator[] of _BinBase which returns by value, I
> overlooked that.
Yes, "val" in "valarray" stands for "value", e.g. a valarr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #24 from Gabriel Dos Reis 2011-06-14
13:54:13 UTC ---
(In reply to comment #18)
> It should be identical to
>
> auto&& range = v1 + v2;
> for (auto b = std::begin(range), e = std::end(range); b != e; ++b)
> { ... }
> (see 6.5.4 [s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #12 from Gabriel Dos Reis 2011-05-17
16:23:37 UTC ---
(In reply to comment #10)
> For sure that works.
>
> Gaby, just to make sure we are on the same page: did you send a message to the
> reflector about this issue already? Or do you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #13 from Gabriel Dos Reis 2011-05-17
16:24:57 UTC ---
(In reply to comment #11)
> All in all, now that I understand the issue with the temporary, this seems
> really sort of a NAD, maybe the wording needs only clarifying that you don'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
--- Comment #7 from Gabriel Dos Reis 2011-05-17
15:14:04 UTC ---
(In reply to comment #6)
> Double Sigh! I was hoping very few overloads would be enough... If we are
> really talking about many I would be in favor of raising the issue, indeed.
T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49022
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #30 from Gabriel Dos Reis 2011-04-29
23:52:32 UTC ---
(In reply to comment #29)
> This is now fixed in 4_6-branch too in C++03 mode, not in C++0x mode, where we
> would need list-initialization of __complex__. If people believe we ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
--- Comment #14 from Gabriel Dos Reis 2011-04-26
14:12:35 UTC ---
(In reply to comment #12)
> (In reply to comment #9)
> > I guess, in the 4.6.1 time frame we can only workaround the issue in C++03
> > mode
> > by doing the piecewise work in the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48760
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101
Summary: obscure error message with std::set
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig.
||2010.12.16 23:22:09
CC||gdr at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Gabriel Dos Reis 2010-12-16
23:22:09 UTC ---
I agree that we should diagnose this case.
--- 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" writes:
| Jason, can you have a look to the errors due to the ambiguous overloading
| pointed out by Benjam
--- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50
---
Subject: Re: numeric_limits::is_modulo is
inconsistent with gcc
On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com
wrote:
> --- Comment #38 from veksler at il dot ibm dot
--- Comment #37 from gdr at integrable-solutions dot net 2010-02-21 18:04
---
Subject: Re: numeric_limits::is_modulo is
inconsistent with gcc
On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org
wrote:
> Or suspend it. I think this warrants a defect rep
--- Comment #27 from gdr at integrable-solutions dot net 2010-02-18 04:59
---
Subject: Re: mixed complex multiplication horribly
inefficient
On Wed, Feb 17, 2010 at 3:24 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #2 from paolo dot carlini at oracle
--- Comment #26 from gdr at integrable-solutions dot net 2010-02-18 04:56
---
Subject: Re: mixed complex multiplication horribly
inefficient
On Wed, Feb 17, 2010 at 4:27 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #9 from paolo dot carlini at oracle
--- Comment #25 from gdr at integrable-solutions dot net 2010-02-18 04:55
---
Subject: Re: mixed complex multiplication horribly
inefficient
On Wed, Feb 17, 2010 at 4:54 PM, jan at epgmod dot phys dot tue dot nl
wrote:
> --- Comment #13 from jan at epgmod dot phys
--- Comment #13 from gdr at integrable-solutions dot net 2010-02-12 11:06
---
Subject: Re: Strange behaviour of valarray::apply method
On Thu, Feb 11, 2010 at 6:22 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #11 from paolo dot carlini at oracle dot com 2010
--- Comment #10 from gdr at integrable-solutions dot net 2010-02-12 00:20
---
Subject: Re: Strange behaviour of valarray::apply method
On Thu, Feb 11, 2010 at 6:08 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #9 from paolo dot carlini at oracle dot com 2010
--- Comment #15 from gdr at integrable-solutions dot net 2010-02-06 22:21
---
Subject: Re: valarray uses __cos which may conflict with
libm functions
On Sat, Feb 6, 2010 at 2:44 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #14 from paolo dot carlini
--- Comment #11 from gdr at gcc dot gnu dot org 2010-02-06 19:17 ---
(In reply to comment #10)
> I'll re-open this only if Gaby, maintainer of valarray, thinks it's the right
> thing to do.
>
If someone wants to rename __cos to _Cos, that is fine by me.
But, it s
--- 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 #8 from gdr at integrable-solutions dot net 2009-01-27 03:34
---
Subject: Re: C99 compat: Can't use the name INFINITY in
an enum.
On Mon, Jan 26, 2009 at 6:19 PM, bkoz at gcc dot gnu dot org
> Thus, I am going to close this as WONTFIX. For C++0x, the
--- Comment #26 from gdr at integrable-solutions dot net 2008-08-26 05:45
---
Subject: Re: Strange -Wunreachable-code warning with _GLIBCXX_DEBUG
On Sat, Aug 23, 2008 at 1:43 PM, paolo dot carlini at oracle dot com
<[EMAIL PROTECTED]> wrote:
> --- Comment #23 from
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
Summary: Incorrect intantiation context yields incorrect codegen
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- 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 ab
--- 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 ma
--- 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.
--- 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 ma
--- 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 ho
--- 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'
--- 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 ma
--- 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.
--- 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.
--- 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 i
--- 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 ma
--- Comment #17 from gdr at gcc dot gnu dot org 2007-12-23 21:22 ---
(In reply to comment #13)
> Gaby --
>
> Paolo and I would like your input on this issue, please.
>
> Thanks,
>
> -- Mark
>
Sorry for replying late -- this issue escaped by attention; Paolo
--- Comment #18 from gdr at gcc dot gnu dot org 2007-11-30 21:10 ---
The program is invalid, there is no point in getting into special
cased corner cases. If you happen to have those macros in the same program
from real world applications, you probably should be watching for
bigger
--- 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
--- Comment #2 from gdr at gcc dot gnu dot org 2007-11-01 02:16 ---
I concur with Lawrence' analysis.
I was bitten by this bug myself in my own code.
--
gdr at gcc dot gnu dot org changed:
What|Removed |
--- 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 #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 #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 #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 #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
: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gdr at gcc dot gnu dot org
GCC build triplet: i686-pc-mingw32
GCC host triplet
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
Native builds of GCC (SVN) fails on i686-pc-mingw32 with:
/home/gdr/Desktop/sandbox/egcs/./prev-gcc/xgcc
-B/home/gdr/Desktop/sandbox/egcs/./prev-gcc/ -B/home/gdr/i686-pc-mingw32/bin/
-c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition
--- 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 #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 gma
--- 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 understa
--- 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
--- 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 ex
--- 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
--- 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
--- 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.
1 - 100 of 1275 matches
Mail list logo
