Synopsis: [parser]compiler does not recognize variable definition
State-Changed-From-To: suspended->closed
State-Changed-By: gdr
State-Changed-When: Sun Dec 29 13:14:02 2002
State-Changed-Why:
Fixed in 3.4 by the new parser.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-tr
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=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=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=54401
Gabriel Dos Reis changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||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.
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=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=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=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=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=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 #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 #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 #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 #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 #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=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=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=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
--- 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 #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=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=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=48101
Summary: obscure error message with std::set
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig.
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=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
--- 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
--- 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=49022
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
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
--- 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 #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 #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 #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=48365
Gabriel Dos Reis changed:
What|Removed |Added
CC||gdr at gcc dot gnu.org
--- Comment #5
--- Comment #24 from gdr at integrable-solutions dot net 2006-04-30 23:05
---
Subject: Re: C-library symbols enter global namespace
"marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #20)
| > the
| > very same sourc
--- Comment #31 from gdr at integrable-solutions dot net 2006-05-01 18:55
---
Subject: Re: hidden declarations klobber STL
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Well, two comments: first, I cannot reproduce with current mainline. Second,
|
--- Comment #32 from gdr at integrable-solutions dot net 2006-05-01 18:59
---
Subject: Re: hidden declarations klobber STL
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| --- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 ---
| (In repl
--- Comment #33 from gdr at integrable-solutions dot net 2006-05-01 19:02
---
Subject: Re: hidden declarations klobber STL
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| I mean, it's a miracle your code actually does what you expect.
:-))
--- Comment #12 from gdr at integrable-solutions dot net 2006-05-01 20:45
---
Subject: Re: goto crossing P.O.D. initialization
"falk at debian dot org" <[EMAIL PROTECTED]> writes:
| I think this is a valid request. While random language extensions aren't
| us
--- Comment #13 from gdr at integrable-solutions dot net 2006-05-01 20:47
---
Subject: Re: goto crossing P.O.D. initialization
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| PR 27252 (aka PR 9278) is another example where C and C++ diff and in fact
--- Comment #14 from gdr at integrable-solutions dot net 2006-05-01 20:48
---
Subject: Re: goto crossing P.O.D. initialization
"acahalan at gmail dot com" <[EMAIL PROTECTED]> writes:
| I only ask that C compatibility be provided for code that would otherwise
fail
|
--- Comment #16 from gdr at integrable-solutions dot net 2006-05-01 23:30
---
Subject: Re: goto crossing P.O.D. initialization
"falk at debian dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #15 from falk at debian dot org 2006-05-01 20:55 ---
| (In repl
--- Comment #7 from gdr at integrable-solutions dot net 2006-05-01 23:39
---
Subject: Re: valarray uses __cos which may conflict with libm functions
"marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #4)
| > Should all th
--- Comment #57 from gdr at integrable-solutions dot net 2006-05-09 15:15
---
Subject: Re: __cplusplus defined to 1, should be 199711L
"marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #30)
| > Defines __cplusplus to 19971
--- Comment #3 from gdr at integrable-solutions dot net 2006-05-11 16:24
---
Subject: Re: New: template function not recognized when invoked with enum
defined in function
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| Compiling this file, with mainline,
--- Comment #6 from gdr at integrable-solutions dot net 2006-05-11 16:47
---
Subject: Re: template function not recognized when invoked with enum defined
in function
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| It was not hastly closed, the curre
--- Comment #9 from gdr at integrable-solutions dot net 2006-05-11 23:20
---
Subject: Re: template function not recognized when invoked with enum defined
in function
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #7)
| > Thi
--- Comment #2 from gdr at integrable-solutions dot net 2006-05-12 21:47
---
Subject: Re: New: no warning for the non-standard integral overloads of math
functions
"marc dot glisse at normalesup dot org" <[EMAIL PROTECTED]> writes:
| As a solution to "bug"
--- Comment #9 from gdr at integrable-solutions dot net 2006-06-21 19:43
---
Subject: Re: use ODR rules to make C++ objects not be TREE_PUBLIC
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Yes this is all undefined but I rather have it be diagnose
--- Comment #8 from gdr at integrable-solutions dot net 2006-06-23 16:35
---
Subject: Re: header dependencies
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| I did implement a version of this myself, basically by writing a
| mapper around each containe
--- Comment #3 from gdr at integrable-solutions dot net 2006-07-02 16:03
---
Subject: Re: Diagnostic about wrong use _Complex prints __complex__
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Confirmed, we don't record in the preprocessor wh
--- Comment #5 from gdr at integrable-solutions dot net 2006-07-02 16:37
---
Subject: Re: Diagnostic about wrong use _Complex prints __complex__
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #3)
| > Indeed. However, we can a
--- Comment #2 from gdr at integrable-solutions dot net 2006-07-17 16:51
---
Subject: Re: New: [4.2 regression] Issue with anonymous namespace
"jakub at redhat dot com" <[EMAIL PROTECTED]> writes:
| template
| const char *baz ()
| {
| return str;
| }
|
| name
--- Comment #6 from gdr at integrable-solutions dot net 2006-07-17 20:19
---
Subject: Re: [4.2 regression] Issue with anonymous namespace
"jason at redhat dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #3 from jason at redhat dot com 2006-07-17 19:53 -
--- 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 #7 from gdr at integrable-solutions dot net 2005-11-16 19:05
---
Subject: Re: [4.0/4.1 regression] '#'obj_type_ref' not supported by dump_expr
"mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Gaby, please apply the simple OB
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-16 19:14
---
Subject: Re: [3.4/4.0/4.1 Regression] bizarre diagnostic on valid (?)
constructor
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| I'm pretty sure I've seen this somewh
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-16 19:28
---
Subject: Re: Koenig found functoid ref, but "cannot be used as a function"
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Actually IIRC Koenig lookup only finds f
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-16 19:43
---
Subject: Re: New: COMPLEX_ASSIGN is wrong
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The defintion of COMPLEX_ASSIGN is wrong,
that is wrong according to Andre
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-16 20:24
---
Subject: Re: COMPLEX_ASSIGN is wrong
"pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes:
| Subject: Re: COMPLEX_ASSIGN is wrong
|
| > yields an lvalue. do whatever you want
--- Comment #6 from gdr at integrable-solutions dot net 2005-11-16 20:27
---
Subject: Re: COMPLEX_ASSIGN is wrong
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I should also note that:
| http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex
|
| r
--- Comment #34 from gdr at integrable-solutions dot net 2005-11-16 20:29
---
Subject: Re: [4.1 regression] Bogus 'is used uninitialized...' warning about
std::complex
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I should also note
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-16 20:39
---
Subject: Re: COMPLEX_ASSIGN is wrong
"pinskia at physics dot uc dot edu" <[EMAIL PROTECTED]> writes:
[...]
| > Subject: Re: COMPLEX_ASSIGN is wrong
| >
| > "pinskia a
--- Comment #9 from gdr at integrable-solutions dot net 2005-11-17 20:46
---
Subject: Re: versioning weak symbols in libstdc++
"jason at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| This code, like the testcase for c++/16021, works fine if the implementatio
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-18 01:31
---
Subject: Re: New: Trivial static const objects should go to .rodata
"msharov at hotmail dot com" <[EMAIL PROTECTED]> writes:
| With the object being initialized at runtime as if it matte
--- Comment #1 from gdr at integrable-solutions dot net 2005-11-22 02:46
---
Subject: Re: New: Needs a warning?
"igodard at pacbell dot net" <[EMAIL PROTECTED]> writes:
| struct foo { const void f(); };
| void foo::f(){}
|
| gets you:
|
| ~/ootbc/members/src$
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-22 03:58
---
Subject: Re: Needs a warning?
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| earth:~>~/ia32_linux_gcc3_0/bin/gcc t.cc
| t.cc:2: prototype for `void foo::f()' does not
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-23 19:36
---
Subject: Re: failure "using" a name contained in a class
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| ICC rejects it as invalid too:
| t.cc(7): error: a class-qua
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-24 03:38
---
Subject: Re: Bootstrap: Failure to build doc/gcc.info
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Actually this is invalid, you need to build with a clean object dir
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-24 09:01
---
Subject: Re: Bootstrap: Failure to build doc/gcc.info
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #4)
| > still does not work with bubblestrap and
--- Comment #8 from gdr at integrable-solutions dot net 2005-11-24 09:03
---
Subject: Re: Bootstrap: Failure to build doc/gcc.info
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| (In reply to comment #3)
| > Subject: Re: Bootstrap: Failure to
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-28 16:15
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I don't see why the w
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-28 16:18
---
Subject: Re: New: Warning "missing braces around initializer" causing
problems with tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| The following code:
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-28 18:46
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| Actually, is a report really
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-29 17:48
---
Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of
bool)
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Hmm, it is looking at the wrong type, it i
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-29 18:02
---
Subject: Re: [3.4/4.0/4.1 Regression] wrong error message (int instead of
bool)
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Hmm, it is looking at the wrong type, it i
--- Comment #2 from gdr at integrable-solutions dot net 2005-11-29 23:20
---
Subject: Re: New: [3.4 Regression] g++.dg/abi/vtt1.C failure with
"-funit-at-a-time"
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The test g++.dg/abi/vtt1.C is
--- Comment #5 from gdr at integrable-solutions dot net 2005-11-30 20:19
---
Subject: Re: typedef in class scope not reported by error message
"brad dot king at kitware dot com" <[EMAIL PROTECTED]> writes:
| Okay, if you don't consider it a bug that is fine with
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-30 22:23
---
Subject: Re: [3.4 Regression] wrong "will never be executed" warning in switch
- case block
"oliverst at online dot de" <[EMAIL PROTECTED]> writes:
| I forgot to meintion, that
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-01 00:10
---
Subject: Re: ostrstream (buf, size) << "..." does not work properly
"igodard at pacbell dot net" <[EMAIL PROTECTED]> writes:
| Two bugs:
with no more details, t
--- Comment #7 from gdr at integrable-solutions dot net 2005-12-02 19:23
---
Subject: Re: exception_defines.h #defines try/catch
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Confirmed. This also causes problems in normal C++ code which doe
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-02 19:18
---
Subject: Re: exception_defines.h #defines try/catch
I agree with Benjamin.
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I personally would like this fixed in libstdc++ a
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-02 19:29
---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #5 from hhinnant at apple dot com 2005-12-02 19:07 --
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-03 00:58
---
Subject: Re: exception_defines.h #defines try/catch
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| We really should not be defining keywords in the headers at all. If
--- Comment #13 from gdr at integrable-solutions dot net 2005-12-03 01:02
---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| (In reply to comment #8)
| > Subject: Re: exception_defines.h
--- Comment #15 from gdr at integrable-solutions dot net 2005-12-03 04:20
---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
| --- Comment #14 from hhinnant at apple dot com 2005-12-03 01:25 --
--- Comment #17 from gdr at integrable-solutions dot net 2005-12-04 02:54
---
Subject: Re: exception_defines.h #defines try/catch
"hhinnant at apple dot com" <[EMAIL PROTECTED]> writes:
[...]
| But I won't apologize for being customer focused.
Geeat! And pe
--- Comment #12 from gdr at integrable-solutions dot net 2005-12-04 17:07
---
Subject: Re: builtin *printf handlers are confused by -fexec-charset
"ghazi at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Backporting this fix to 3.4 requires also backporting th
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-07 20:40
---
Subject: Re: New: [3.4 regression] ICE for sizofe of incomplete type
"reichelt at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| The testcase gcc.dg/noncompile/920923-1.c causes a
--- Comment #5 from gdr at integrable-solutions dot net 2005-12-07 23:42
---
Subject: Re: std::fill_n, std::generate_n incorrect signature
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Related to PR 16505. This is the same issue as PR 16505.
|
| C
--- Comment #9 from gdr at integrable-solutions dot net 2005-12-08 03:32
---
Subject: Re: std::fill_n, std::generate_n incorrect signature
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| FWIW, I think Andrew makes a good point in comment #1. The algorithms
--- Comment #1 from gdr at integrable-solutions dot net 2005-12-08 03:36
---
Subject: Re: New: fill_n, generate_n assume Size is modifiable
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| I came across this while gathering background for my post in
| c++s
--- Comment #11 from gdr at integrable-solutions dot net 2005-12-08 16:04
---
Subject: Re: std::fill_n, std::generate_n incorrect signature
"sebor at roguewave dot com" <[EMAIL PROTECTED]> writes:
| No, I don't. The standard is clear and most of us seem to th
--- Comment #14 from gdr at integrable-solutions dot net 2005-12-08 16:23
---
Subject: Re: std::fill_n, std::generate_n incorrect signature
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| 2- As I see the issue, it depends a lot on the actual timeframe o
--- Comment #16 from gdr at integrable-solutions dot net 2005-12-08 17:12
---
Subject: Re: std::fill_n, std::generate_n incorrect signature
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| + the more general consideration that, delivering a C++0x conf
--- Comment #2 from gdr at integrable-solutions dot net 2005-12-08 22:25
---
Subject: Re: New: POD structures can have
"mrs at apple dot com" <[EMAIL PROTECTED]> writes:
| A user reported that this:
|
| mrs $ cat > t98.c
| struct X {
|
--- Comment #8 from gdr at integrable-solutions dot net 2005-12-12 17:37
---
Subject: Re: (optimisation) Functions in anonymous namespaces should default
to "hidden" visibility
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| There is a
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-15 03:40
---
Subject: Re: condensed nested namespaces
"bkoz at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| --- Comment #5 from bkoz at gcc dot gnu dot org 2005-12-14 17:16 ---
|
| I'
1 - 100 of 1275 matches
Mail list logo
