--- Comment #3 from redi at gcc dot gnu dot org 2010-09-23 10:14 ---
The example was wrong, fixed by DR 497
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#497
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-23 13:58 ---
set LD_LIBRARY_PATH so the dynamic loader can find libmpc.so.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45760
--- Comment #3 from redi at gcc dot gnu dot org 2010-09-23 14:08 ---
GCC doesn't set runpaths in executables, this is intentional:
http://gcc.gnu.org/faq.html#rpath
If you don't want those support libs installed for their own sake and are only
installing them for GCC to use
--- Comment #4 from redi at gcc dot gnu dot org 2010-09-23 14:14 ---
this should be documented, either under the --with-gmp configuration docs or in
the faq
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from redi at gcc dot gnu dot org 2010-09-23 15:28 ---
I'm going to add something to the docs, so I'll keep this PR open until I do
that, so reopening ...
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from redi at gcc dot gnu dot org 2010-09-23 15:28 ---
... and assigning to myself again
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-23 15:59 ---
It should be the same as C (as if done by printf) and our implementation relies
on the C library to do it correctly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45762
--- Comment #2 from redi at gcc dot gnu dot org 2010-09-22 15:27 ---
Looks like a dup of PR 45625
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45747
--- Comment #4 from redi at gcc dot gnu dot org 2010-09-22 23:22 ---
(In reply to comment #3)
This seems to me an instance of don't do it when it hurts, no? Thanks.
That was my first thought when I saw this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28756
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #5 from redi at gcc dot gnu dot org 2010-09-20 15:54 ---
PR 41437 has a simpler testcase
*** This bug has been marked as a duplicate of 41437 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2010-09-20 15:54 ---
*** Bug 40843 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2010-09-18 13:20 ---
*** This bug has been marked as a duplicate of 44645 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from redi at gcc dot gnu dot org 2010-09-18 13:20 ---
*** Bug 45717 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2010-09-18 00:26 ---
I nearly *always* build with ../gcc/configure --enable-libstdcxx-debug and
haven't seen this on GNU/Linux (I'm not saying Makefile.am is right, just that
the problem isn't apparent for me)
--
http://gcc.gnu.org
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-17 01:25 ---
The 'typename' should not be necessary, and 4.5 and 4.6 compile it without
problems
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45698
--- Comment #8 from redi at gcc dot gnu dot org 2010-09-15 23:43 ---
Hmm, OK, I can reproduce that with a current 4.5.2 build, but not with a
snapshot from last week. Please file a separate bug for that, component=c++ -
thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403
--- Comment #9 from redi at gcc dot gnu dot org 2010-09-15 23:52 ---
oops, I wasn't paying attention - I screwed up my build of gdb-7.2 so it didn't
have python support and mistook the non-pretty printed string for a traceback!
Here is a fresh GCC 4.5.2 build and a vanilla GDB 7.2
--- Comment #6 from redi at gcc dot gnu dot org 2010-09-15 11:21 ---
(In reply to comment #5)
with -gdwarf-4 enabled it fails on gdb-7.2 with runtime error:
I couldn't reproduce that with 4.5.2 20100909, can you give more details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from redi at gcc dot gnu dot org 2010-09-14 12:47 ---
looks sensible, I'll do that
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-13 16:55 ---
Not a regression, and G++ 4.6 correctly rejects it:
pr.cc:12:8: error: looser throw specifier for 'virtual Derived::~Derived()
throw (Viral::Dose)'
pr.cc:9:11: error: overriding 'virtual Base::~Base() throw ()'
EDG
--- Comment #3 from redi at gcc dot gnu dot org 2010-09-13 17:04 ---
the test already includes cassert so presumably the fix is simply to replace
line 77 with
T const* operator-() const { assert(this-is_initialized()) ; return
this-get_ptr_impl() ; }
--
http://gcc.gnu.org
--- Comment #3 from redi at gcc dot gnu dot org 2010-09-13 17:06 ---
Jason, do you know if this was fixed as part of your noexcept work, or is it
still latent in trunk?
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from redi at gcc dot gnu dot org 2010-09-10 09:55 ---
There certainly is a race condition: there's no ordering between pthread_cancel
and pthread_testcancel so the main thread can run f2(50) before thread2 calls
pthread_cancel, which is why you see it sometimes run
--- Comment #17 from redi at gcc dot gnu dot org 2010-09-10 10:11 ---
(In reply to comment #15)
In particular, it does not appear that the thread is being reliably cancelled
at the pthread_testcancel call - sometimes f2 seems to run beyond the
pthread_testcancel,
As I said above
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-09 16:31 ---
I agree this would be useful, I've had problems with such shadowing when moving
members higher in inheritance hierarchies and accidentally missing occurrences
in some derived classes.
4.2 is unmaintained now
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-09 19:19 ---
this isn't specific to strstreams
#include iostream
#include sstream
using namespace std;
int main()
{
stringstream io;
io.ios::fill('@');
io.flags(ios::internal);
io.width( 10 );
io (void
--- Comment #4 from redi at gcc dot gnu dot org 2010-09-09 20:23 ---
See Table 61 in C++ 2003 (or table 88 in C++0x draft) - the 4.4 behaviour is
correct
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-09-09 23:51 ---
I agree the lookup in get_value should find the template parameter, not
Outer::value.
Here's a variation that should not compile, because value should be invalid
struct Outer
{
static const int value = 1
--- Comment #7 from redi at gcc dot gnu dot org 2010-09-07 19:50 ---
(In reply to comment #0)
Calling ios::sync_with_stdio(false) before the loop start reduces the time per
line to around 0.3us, on par with fgets(). This suggests that the problem is
with the stdio synchronisation
--- Comment #19 from redi at gcc dot gnu dot org 2010-09-07 01:44 ---
Manu, did you mean to change Severity back to 'critical' ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468
--- Comment #5 from redi at gcc dot gnu dot org 2010-09-07 02:16 ---
(In reply to comment #3)
I think there is a dup of this bug without auto. Not to mention it was
defect report against the standard.
Bug 11407 / DR 115 ? That should be fixed in 4.5.0
--
http://gcc.gnu.org
--- Comment #9 from redi at gcc dot gnu dot org 2010-08-29 11:28 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1944 proposed the
changes to sequencing wording, revised in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2239.html
The new wording makes it clear
--- Comment #12 from redi at gcc dot gnu dot org 2010-08-29 20:50 ---
(In reply to comment #10)
However you beg the question because you assume that evaluation of operands
means evaluation of rvalues derived from the operands.
I assume nothing of the sort.
It does not; it means
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-29 22:39 ---
Here's a reduced testcase, struct s is not relevant:
bool f(bool b) {
b = true;
return false;
}
int main() {
bool b = false;
b |= f(b);
return b;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
--- Comment #29 from redi at gcc dot gnu dot org 2010-08-28 14:39 ---
that's why EDG only gives a remark not a warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #30 from redi at gcc dot gnu dot org 2010-08-28 14:42 ---
Can we change the summary to mention references? It looks to me as though it's
talking about the address-of operator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=986
--- Comment #7 from redi at gcc dot gnu dot org 2010-08-28 23:48 ---
(In reply to comment #6)
Thank you. Don't know about C, but this is C++ in which operators are
function.
Builtin operators are not functions.
See e.g. footnote 12 on 1.9p18 in C++ 2003 which makes it clear
--- Comment #8 from redi at gcc dot gnu dot org 2010-08-29 00:55 ---
The sequencing rules have changed in C++0x, but G++ doesn't implement them yet
AFAIK, and I'm not sure if the new rules affect this example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-27 15:15 ---
(In reply to comment #0)
(void(*)(void)) my_fun_T // This is test.cpp:22
Can I assume you meant to case to (void(*)(void*)) here?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-27 15:21 ---
(In reply to comment #1)
(In reply to comment #0)
(void(*)(void)) my_fun_T // This is test.cpp:22
Can I assume you meant to case to (void(*)(void*)) here?
With that change 4.5 and 4.6 compile the code
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-27 19:10 ---
4.5 and 4.6 give the column number, but of the closing brace, which is no
better
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-26 10:14 ---
You didn't say which version of GCC you're using, but it doesn't really matter
because these options have been in place for many years.
(In reply to comment #0)
(5) I'm lazy and don't want to locate the applicable
--- Comment #5 from redi at gcc dot gnu dot org 2010-08-26 15:09 ---
(In reply to comment #4)
(In reply to comment #0)
(5) I'm lazy and don't want to locate the applicable man page
Here it is:
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Interesting. I was going
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #4 from redi at gcc dot gnu dot org 2010-08-25 12:21 ---
(In reply to comment #3)
So, how do we report bugs in the C standard?
Try the comp.std.c newsgroup
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36483
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-25 14:12 ---
It's nothing to do with unordered_map, it's std::string, and it fails because
lazy_string was added in GDB 7.1
we can probably do something like
if (gdb.VERSION == '7.0'):
return '' + self.val
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-25 14:17 ---
Tom, I don't remember if the decision to use lazy_string (and therefore require
GDB 7.1) was intentional - is a fallback worthwhile?
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-24 15:36 ---
(In reply to comment #0)
Also, compare_swap is not declared. Instead, compare_exchange_weak(strong)
exist. It is not a bug, but is not consistent with the document.
http://www.open-std.org/jtc1/sc22/wg21/docs
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c++ |libstdc
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-24 15:49 ---
confirmed, for 4.5 and 4.6 the relevant header is atomic not cstdatomic
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-23 11:22 ---
this report isn't much help - does the warning occur when building the library,
or using it?
and I doubt it makes any difference, but you've reported it against 4.5.1 and
then said you're using 4.5.0
The warning
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-23 11:35 ---
(In reply to comment #2)
This is building libstdc++ 4.5.1.
You can sort of tell from the path.
I build in obj. I don't install to obj.
Ah yeah - the report would have been more useful with that info though, so
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-23 13:17 ---
The summary seems backwards: the conversion shouldn't generate operator==,
instead using operator== should trigger the conversion, but fails to when the
conversion operator is a template.
Strangely, adding a non
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-23 22:01 ---
(In reply to comment #2)
BTW, Visual Studio (2010) has different behavior -- it accepts both of the
statements in main(), even though they require different parse trees.
EDG (Comeau) also accepts them both
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-20 15:36 ---
Yes, if (b = 2) is valid and -Wparentheses warns about that.
(In reply to comment #0)
It would be nice if future version could at least throw a warning.
Obviously it can't be anything *more* than a warning.
N.B
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-19 12:11 ---
Bug 16189 and Bug 36888
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45331
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-19 12:13 ---
Probably Bug 44645
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45334
--- Comment #4 from redi at gcc dot gnu dot org 2010-08-19 12:19 ---
*** Bug 45181 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from redi at gcc dot gnu dot org 2010-08-19 12:19 ---
*** This bug has been marked as a duplicate of 44645 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from redi at gcc dot gnu dot org 2010-08-19 12:22 ---
*** Bug 45334 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-19 12:22 ---
works with 4.4 and 4.6, so I'm marking it as a dup
*** This bug has been marked as a duplicate of 44645 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from redi at gcc dot gnu dot org 2010-08-19 12:26 ---
(adjusting title to be more general)
testcase from dup Bug 45181
struct S { int f(S*); };
int S::f(S* p)
{
return 0;
}
int main()
{
S s;
return s.f(s);
}
within S::f p has type void*
Tom, CCing you
--- Comment #7 from redi at gcc dot gnu dot org 2010-08-19 12:32 ---
testcase from Bug 45334 reduced to a single file:
struct Base
{
virtual ~Base();
};
Base::~Base() {}
struct Derived : Base
{
virtual ~Derived();
void foo();
};
Derived::~Derived() {}
void Derived::foo
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-19 14:52 ---
template parameters must have linkage, but an unnamed type has no linkage
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-19 14:53 ---
N.B this has nothing to do with arrays, the following fails for the same
reason:
templateclass T
void func (T);
static struct
{
int i;
}
arr;
void test()
{
func(arr);
}
--
http://gcc.gnu.org
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-18 22:54 ---
possibly related to Bug 44703, although that's fixed in 4.5.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45328
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-17 09:38 ---
(In reply to comment #1)
IMHO this isn't a bug, to simplify that into an integer you really need some
optimizations. The conversion looks very weird, if you use something saner
The conversion uses this extension
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-17 09:42 ---
Looking at the diagnostics issued when -pedantic is added, I think the right
conversion is
(void*)(plain_foobar_t)Foo::foobar
That still uses the G++ extension, and doesn't give the asm error even without
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-16 17:33 ---
Does the user report say anything else?
Is this when using -std=c++98 -pedantic-errors? Something else?
They're not used unconditionally, they're guarded by C99-related macros.
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from redi at gcc dot gnu dot org 2010-08-16 18:13 ---
Ah I see the problem now, sorry. Even when we're using C99 features,
'restrict' is never a keyword for C++.
Does __restrict even have any effect on declarations (rather than definitions
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-15 19:38 ---
I don't think adding -std=posix is the right solution, since dlsym needs to be
usable if users choose other options such as -std=c++0x or -std=gnu99
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289
--- Comment #53 from redi at gcc dot gnu dot org 2010-08-14 13:55 ---
(In reply to comment #52)
(In reply to comment #51)
There you go, you are now famous.
http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism
Why did you remove the post? Do you think something
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-14 14:00 ---
You probably want something like
bool operator(const E e2) const
{
return x != e2.x ? x e2.x : a e2.a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45284
--- Comment #54 from redi at gcc dot gnu dot org 2010-08-14 14:25 ---
(In reply to comment #53)
GCC compiles that fine, try it.
Sorry, I forgot my manners, what I meant is...
Why don't you think before shooting off some crap.
So I have shown you talk crap. Do you like it?
Better get
--- Comment #57 from redi at gcc dot gnu dot org 2010-08-14 15:09 ---
(In reply to comment #55)
(In reply to comment #53)
Look at the page history, it was removed by someone else, probably because
your
comment is badly written and not suitable for the Wikipedia page.
I
--- Comment #59 from redi at gcc dot gnu dot org 2010-08-14 17:10 ---
(In reply to comment #58)
(is Chris your friend?)
Of course not. I have no idea who he is.
Are you confusing me with Michael? I've not said anything about LDT.
Yes I am. I'm sorry for that, I really am. I
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-14 20:01 ---
Subject: Bug 45283
Author: redi
Date: Sat Aug 14 20:00:55 2010
New Revision: 163250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163250
Log:
2010-08-14 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #4 from redi at gcc dot gnu dot org 2010-08-15 00:36 ---
Subject: Bug 45283
Author: redi
Date: Sun Aug 15 00:36:16 2010
New Revision: 163259
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163259
Log:
2010-08-15 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #5 from redi at gcc dot gnu dot org 2010-08-15 00:37 ---
Fixed for 4.5.2 and 4.6.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from redi at gcc dot gnu dot org 2010-08-13 10:51 ---
But surely if (as you suggest) swscanf had a DIE without DW_AT_external that
would imply it was private to the compilation unit, which would be wrong.
If a non-static function has a DIE, it should include
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-13 11:05 ---
(In reply to comment #7)
Also, how does on locate the DIEs for variables/functions that are listed in
the .debug_pubnames section($ eu-readelf -wpubnames file). The list of
variables/functions that are *defined
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-13 11:50 ---
(In reply to comment #0)
I propose to add a more detailed documentation (though I don't know the exact
place where to add it).
maybe http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html
The html docs
--- Comment #45 from redi at gcc dot gnu dot org 2010-08-13 16:32 ---
Congratulations. Are you done now?
What else are you hoping to achieve?
Is this a cry for attention?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #49 from redi at gcc dot gnu dot org 2010-08-13 22:38 ---
Please, start a blog and write your views somewhere else. PLEASE.
You're rude, ignorant and annoying.
(In reply to comment #48)
of why it is important to be able to initialize classes as function
parameters
You
--- Comment #50 from redi at gcc dot gnu dot org 2010-08-13 22:40 ---
Oh, and if you do get people to understand that pointer arithmetic is not
always well-defined, that would be a good thing. There are other people who
share you're incorrect understanding of the C and C++ languages
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-14 00:19 ---
oops, I see the problem
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from redi at gcc dot gnu dot org 2010-08-12 15:52 ---
(In reply to comment #6)
(In reply to comment #4)
Pretty please, before filing further bugs take time and learn C.
The pointer subtraction triggers undefined behavior, because one pointer
points
to one object
--- Comment #12 from redi at gcc dot gnu dot org 2010-08-12 16:09 ---
Seriously, go away. I'll get far ruder if you're going to open bug reports
worded like this:
(In reply to comment #0)
Don't bother trying to understand why I need the operand to work as stated
in
C99, or why I
--- Comment #16 from redi at gcc dot gnu dot org 2010-08-12 16:17 ---
(In reply to comment #15)
char* p1=random_address();
char* p2=another_random_address();
p1-p2 is always well defined, no matter to which objects they point to.
No. No it isn't. It really isn't.
(In reply
--- Comment #19 from redi at gcc dot gnu dot org 2010-08-12 16:20 ---
Everyone understands it, you're just wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
--- Comment #25 from redi at gcc dot gnu dot org 2010-08-12 17:53 ---
(In reply to comment #23)
Maybe you do a good job when you quickly send them away after stamping it with
non-conformant, I don't know, but I expected a little more interest on your
part to make GCC better. I would
--- Comment #17 from redi at gcc dot gnu dot org 2010-08-11 11:55 ---
As already stated, what you are doing is not valid C or C++, the standards do
not guarantee the behaviour you are expecting w.r.t stack layout, and an
optimising C or C++ compiler follows the rules of the language
--- Comment #19 from redi at gcc dot gnu dot org 2010-08-11 14:10 ---
(In reply to comment #18)
Of course vsnprintf was my first choice, as you can see from the WIN32 part of
the code I sent you. In WIN32 I can use vsnprint in a very natural and
predictable way in format_indirect
--- Comment #24 from redi at gcc dot gnu dot org 2010-08-11 17:57 ---
(In reply to comment #22)
If GCC supports cdecl on a x86 plaform then it must support the packing of
parameters as defined for x86 (it is not standardize that I know of, but it is
well defined). I sugest reading
--- Comment #34 from redi at gcc dot gnu dot org 2010-08-11 21:27 ---
(In reply to comment #25)
In other words my code is not portable because GCC is not doing what it
should.
GCC causes code not to be portable a lot of times, like in the following case
(which does not compile
--- Comment #5 from redi at gcc dot gnu dot org 2010-08-10 09:16 ---
You have not found a bug in GCC and this is not the place to learn C++.
Please find a reference on C++ iostreams or find an appropriate forum to ask
questions.
You can call is_open() to see if the stream was opened
--- Comment #13 from redi at gcc dot gnu dot org 2010-08-11 00:15 ---
Yes, I agree. I think it would be good to add the overloads, they can always be
adjusted before 4.6 if they don't match the wording Alisdair proposes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42925
1 - 100 of 682 matches
Mail list logo
