[Bug c++/35101] Const object creation with mutable field
--- 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 Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35101
[Bug other/45760] GCC build fails: can't find MPC
--- 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
[Bug other/45760] GCC build fails: can't find MPC
--- 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, then a simpler way to build it is to put the
gmp, mpfr and mpc sources under gcc-4.5.1 (renamed from gmp-x.y.z to just gmp,
and similarly for mpfr and mpc) and then just configure gcc without any
--with-{gmp,mpfr,mpc} options. That way gcc will build with those sources and
doesn't need to find the shared libs.
Or you can build the libs with --disable-shared so that gcc will have to link
statically to libgmp.a, which also avoids needing to find the shared libs.
Or you can just make sure the shared lib can be found, using LD_LIBRARY_PATH or
LD_RUN_PATH or ldconfig.
(In reply to comment #0)
But libmpc.so.2 is there. I even took care of creating artificial symbolic
links to satisfy this bizarre 'powerpc64-unknown-linux-gnu' under ROOT.
Don't do that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45760
[Bug bootstrap/45760] GCC build fails: can't find MPC
--- 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 AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|other |bootstrap Ever Confirmed|0 |1 Keywords||documentation Last reconfirmed|-00-00 00:00:00 |2010-09-23 14:14:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45760
[Bug bootstrap/45760] GCC build fails: can't find MPC
--- 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 Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45760
[Bug bootstrap/45760] GCC build fails: can't find MPC
--- 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 Status|REOPENED|ASSIGNED Last reconfirmed|2010-09-23 14:14:55 |2010-09-23 15:28:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45760
[Bug c++/45762] Same binary prints sign of nan on different systems.
--- 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
[Bug c++/45747] Enums are stronger than templates
--- 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
[Bug bootstrap/28756] `make install` is broken, doesn't install `gcc` when program_prefix == ${triplet}-
--- 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
[Bug c++/41437] No access control for classes in template functions
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.6 4.4.3 4.5.2 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-09-20 15:53:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
[Bug c++/40843] access violation not detected for non dependent qualified enum value
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40843
[Bug c++/41437] No access control for classes in template functions
--- 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 CC||sipych at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437
[Bug debug/45717] [4.5 Regression] regression in debug info on simple C++ code
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45717
[Bug debug/44645] [4.5 Regression] missing debug info for pointer types
--- 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 CC||charlet at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug libstdc++/45711] Building with --enable-libstdcxx-debug fails during install
--- 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/bugzilla/show_bug.cgi?id=45711
[Bug web/45688] Typo in __attribute__((version-id)) docs
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||documentation Last reconfirmed|-00-00 00:00:00 |2010-09-16 11:42:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45688
[Bug c++/45698] C++0x Variadic Templates: Infinite template recursion rather than an error message
--- 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
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
--- 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
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
--- 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 build (with python
support!)
moria:shm$ cat pr45403.cc
#include string
int main()
{
std::string s( foo );
s.size();
}
moria:shm$ ~/gcc/4.5/bin/g++ pr45403.cc -v 21 | fgrep 'version 4.5'
gcc version 4.5.2 20100915 (prerelease) (GCC)
GNU C++ (GCC) version 4.5.2 20100915 (prerelease) (x86_64-unknown-linux-gnu)
GNU C++ (GCC) version 4.5.2 20100915 (prerelease) (x86_64-unknown-linux-gnu)
moria:shm$
moria:shm$ ~/gcc/4.5/bin/g++ pr45403.cc -gdwarf-4 -g2 -Wl,-R$HOME/gcc/4.5/lib64
moria:shm$
moria:shm$ /dev/shm/gdb/bin/gdb ./a.out
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-unknown-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /dev/shm/a.out...done.
(gdb) br main
Breakpoint 1 at 0x4007cd: file pr45403.cc, line 4.
(gdb) r
Starting program: /dev/shm/a.out
Breakpoint 1, main () at pr45403.cc:4
4 std::string s( foo );
(gdb) n
5 s.size();
(gdb) p s
$1 = foo
Are you sure you haven't modified your GCC sources?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
--- 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=45403
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
--- 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 AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-14 12:47:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403
[Bug c++/45657] Wrongly computed exception specification for destructor
--- 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 (Comeau online) also accepts it. -- redi at gcc dot gnu dot org changed: What|Removed |Added Keywords||accepts-invalid Known to work||4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45657
[Bug c++/45645] pr44972.C fails with error: �__assert_fail� was not declared in this scope
--- 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/bugzilla/show_bug.cgi?id=45645
[Bug c++/45657] Wrongly computed exception specification for destructor
--- 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 CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45657
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- 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 beyond the cancellation point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug c++/45479] Exceptions not delivered properly after thread cancellation
--- 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, that's consistent with f2(50) executing before pthread_cancel. which causes the throw to execute, and results in an abort (seems to want to act like an uncaught exception propagated out). If you comment out the throw, f2 will sometimes continue to construct additional objects past 50. I have also noticed that sometimes a bunch of the Y objects get destructed, but then the program suddenly summarily exits. I think that's because f2(50) leaves cancellation enabled and writing to cout is a cancellation point, so the exit happens when some ~Y destructor coincides with thread2 calling pthread_cancel. I also tried setting the cancellation type to asynchronous, but that doesn't make any difference - sometimes it works, sometimes it don't. Its very unpredictable. Yes, race conditions tend to have unpredictable results. If I change the condition in f2 to (i = 50) and disable cancellation again after the call to pthread_testcancel then I get more predictable behaviour, because that ensures that the only cancellation points are the calls to pthread_testcancel in f2, which still occur in f2(51), f2(52) etc. i.e. cancellation still occurs at the intended place even if f2(50) happens before the call to pthread_cancel. That seems to validate my theory that the cancel happens after f2(50), and so takes effect at the first cancellation point after the cancellation request. I don't think there's a gcc or glibc bug here, just non-portable code with indeterminate behaviour. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479
[Bug c++/45615] -Wshadow doesn't report class member shadowing
--- 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, but current releases don't warn either. -- redi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2010-09-09 16:31:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45615
[Bug c++/45606] [4.5/4.6 Regresssion] match a method prototyped a typedef alias with the original type (using stdlib)
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to work||4.4.4 Last reconfirmed|-00-00 00:00:00 |2010-09-09 16:31:41 date|| Summary|match a method prototyped a |[4.5/4.6 Regresssion] match |typedef alias with the |a method prototyped a |original type (using stdlib)|typedef alias with the ||original type (using stdlib) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45606
[Bug c++/45618] GCC 4.4.4 strstream and ios::internal flag
--- 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 *) 123 ' ';
cout String: io.str() endl;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618
[Bug c++/45618] GCC 4.4.4 strstream and ios::internal flag
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618
[Bug c++/45625] Template parameter name does not hide outer class scope's member name
--- 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 ;
template int value
struct Inner
{
static const int* get_value() { return value ; }
} ;
} ;
template class Outer::Inner2;
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-09-09 23:51:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45625
[Bug libstdc++/45574] ifstream::getline() is extremely slow
--- 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 code. It's well known (though maybe not well enough) that you should use sync_with_stdio(false) to get good performance, unless you specifically need the synchronisation. (In reply to comment #4) Benchmarking on Solaris indicates that cin.getline() takes only 1us per iteration there, but I don't think the source code is available, so it's hard to provide details. If you mean the classic iostreams provided with Sun Studio (rather than GCC on Solaris or something else) then that stream library is not standard-conforming and you're comparing apples and oranges. If you mean the STLport iostreams provided with Sun Studio and enabled by -library=stlport4, the source is available, but I'd be surprised if you see a significant speed difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'
--- 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
[Bug c++/45523] [C++0x] Failure to bind auto variable to function template instance
--- 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/bugzilla/show_bug.cgi?id=45523
[Bug c++/45437] Loses reference during update
--- 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 that a compound assignment such as |= has this sequence: - evaluation of operands - assignment - evaluation of assignment expression i.e. evaluating result of (a|=b) for use in another expression However I don't think that affects this case. The builtin |= operator is not a function (see 5p2) and does not obey the rules of operand types of function calls, so it is not appropriate to describe the effects in terms of bool c = a; bool d = f(); operator|=(c, d) The operand to the builtin |= is an lvalue expression, not a reference. The new wording also makes it clear it is only evaluated once, before the assignment. It is not specified whether evaluation of the left operand is sequenced before evaluation of the right operand, therefore the compiler is still permitted to evaluate sz.b (as false) then evaluate f(...) ( also false) then perform the assignment of sz.b=(false|false) Thus, invalid. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- 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 evaluation of an lvalue (i.e. a reference) Of course it means an lvalue, but that does not imply a reference. If you read Clause 5 you'll see that the requirements on operands are in terms of lvalues, rvalues etc. and not references. You're still assuming that invocation of a builtin operator results in a function call, and reasoning in terms of the requirements of a function call. 5p2 makes it clear that the requirements on operands of builtin operators are different to the requirements on function calls. If that was not the case, why would the standard say that replacing a builtin operator with a user-defined oeprator uses the requirements of a function call? and an rvalue respectively, because otherwise the assignment would not have an lvalue to assign to. Hence the function f() must be called before |= (the assignment) is performed. Yes, f() is called before the assignment, but it is indeterminately sequenced w.r.t the evaluation of sz.b -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- 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
[Bug c++/986] g++ misses warning for on temporary
--- 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
[Bug c++/986] g++ misses warning for on temporary
--- 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
[Bug c++/45437] Loses reference during update
--- 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 that builtin operators have very different effects wrt sequence points from user-defined functions: 12) The operators indicated in this paragraph are the built-in operators, as described in clause 5. When one of these operators is over-loaded (clause 13) in a valid context, thus designating a user-defined operator function, the expression designates a function invocation, and the operands form an argument list, without an implied sequence point between them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
[Bug c++/45437] Loses reference during update
--- 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
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- 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
[Bug c++/45428] Address of template function even if fully named as a template-id is not properly determined
--- 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, but don't link -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45428
[Bug c++/45431] initializer-string for array of chars is too long: which one?
--- 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
[Bug c++/45411] Please add -Wno-unused-variable and friends compiler warning options
--- 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 man page
Here it is:
http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
(9) no easy way to control 'unused warning' spew is one of the biggest
complaints on the crypto++ mailing list when building for *nix
This gives neither unused variable not unused parameter warnings:
void f(int) {
int j = 0;
(void)j;
}
But if that's not easy enough, just use relevant -Wno-... option.
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45411
[Bug c++/45411] Please add -Wno-unused-variable and friends compiler warning options
--- 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 to cite the same page. Searching for -Wno-unused-parameter on the page returns 0 results. Under -Wunused-parameter, the page states, Warn whenever a function parameter is unused aside from its declaration. To suppress this warning use the `unused' attribute (see Variable Attributes). (But no mention of -Wno-unused-parameter). Near the top of the page, in the paragraph beginning you can request it says: Each of these specific warning options also has a negative form beginning `-Wno-' to turn off warnings; for example, -Wno-implicit. This manual lists only one of the two forms, whichever is not the default. It would be a waste of time to say it on every option. Since I feel like a total ass, perhaps someone can close this feature request. It's closed :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45411
[Bug c++/45378] [C++0x] Narrowing error not detected
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2010-08-25 11:35:41 date|| Summary|Narrowing error not detected|[C++0x] Narrowing error not ||detected http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45378
[Bug c++/36483] Getting an address of a byte-aligned field declared as a bit-field should be allowed
--- 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
[Bug libstdc++/45403] broken python pretty printer for unordered_map.
--- 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['_M_dataplus']['_M_p'].string (length = len) + '' return self.val['_M_dataplus']['_M_p'].lazy_string (length = len) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403
[Bug libstdc++/45403] python pretty printer for std::string requires GDB 7.1
--- 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 |Added CC||tromey at gcc dot gnu dot ||org Summary|broken python pretty printer|python pretty printer for |for unordered_map. |std::string requires GDB 7.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403
[Bug c++/45398] Missing atomic_Tp*::store definition
--- 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/papers/2007/n2427.html n2427 is ancient, the implementation in libstdc++ is based on a working draft of the standard (maybe n3000, I don't recall exactly which one) not an early proposal -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45398
[Bug libstdc++/45398] [C++0x] Missing atomic_Tp*::store definition
-- redi at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c++ |libstdc++ Summary|Missing atomic_Tp*::store |[C++0x] Missing |definition |atomic_Tp*::store ||definition http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45398
[Bug libstdc++/45398] [C++0x] Missing atomic_Tp*::store definition
--- 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 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-24 15:49:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45398
[Bug libstdc++/45347] concurrence.h: In constructor '__gnu_cxx::__cond::__cond()': /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++-v3/include/ext/concurrence.h:276:29: warning: missing initialize
--- 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 means that the Tru64 definition of the PTHREAD_COND_INITIALIZER macro doesn't give an initializer for a member of the Tru64 definition of pthread_cond_t, so there's nothing libstdc++ can do except suppress the warning by adding #pragma GCC system_header to that file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45347
[Bug libstdc++/45347] concurrence.h: In constructor '__gnu_cxx::__cond::__cond()': /home/jayk/obj/gcc451/alphaev67-dec-osf5.1/libstdc++-v3/include/ext/concurrence.h:276:29: warning: missing initialize
--- 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 there's no need to infer it from your choice of path. The bootstrap compiler might have been 4.5.0. Presumably it was, or showing the output of gcc -v wasn't much use either :) I can do it again with 4.5.1 as bootstrap. That's not likely to help. As I said, the warning is caused by definitions in the OS headers, which just get used in the libstdc++ header. I actually think this gcc warning generally shouldn't even exist, unless maybe presented with a union whose first member is not its largest. Though perhaps gcc should do what Microsoft C does there -- always zero the entire thing. That's what GCC does, as required by the standard. Presumably that's exactly what's intended and the Tru64 PTHREAD_COND_INITIALIZER macro relies on that happening, so there's no problem. I agree the warning isn't often useful, which is why it's not part of -Wall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45347
[Bug c++/45383] [4.5/4.6 Regression] Implicit conversion to pointer does no longer automatically generate operator== and operator!=.
--- 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-template conversion operator causes template argument
deduction to succeed, even though the non-template operator isn't used
e.g.
#include iostream
struct null {
null() {}
templateclass T
operator T*() const {
return 0;
}
templateclass C, class T
operator T C::*() const {
return 0;
}
private:
operator double*() const; // ???
null(const null);
null operator=(const null);
void operator() const;
};
static struct null null;
int main() {
int* ptr = null;
std::cout (ptr == null) , (ptr != null);
return 0;
}
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|(many, read below) |
GCC host triplet|(many, read below) |
GCC target triplet|(many, read below) |
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2010-08-23 13:17:12
date||
Summary|[g++ = 4.5 ] Implicit |[4.5/4.6 Regression]
|conversion to pointer does |Implicit conversion to
|no longer automatically |pointer does no longer
|generate operator== and |automatically generate
|operator!=. |operator== and operator!=.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45383
[Bug c++/45374] template keyword incorrectness// failure to parse valid code.
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45374
[Bug c/45358] =+ oddness
--- 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. at least in C++ there are valid reasons to use the + operator, such as turning an lvalue into an rvalue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45358
[Bug c++/45331] Generate clear diagnostics when a semicolon is missing at the end of a class definition
--- 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
[Bug c++/45334] Base class type information not accessible in binaries compiled with g++ 4.5.0
--- 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
[Bug debug/44645] [4.5 Regression] wrong debug info for nested typedef
--- 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 CC||nikolay at totalviewtech dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug debug/45181] No debug information for parameter type
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45181
[Bug debug/44645] [4.5 Regression] wrong debug info for nested typedef
--- 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 CC||andre dot poenitz at nokia ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug c++/45334] Base class type information not accessible in binaries compiled with g++ 4.5.0
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45334
[Bug debug/44645] [4.5 Regression] missing debug info for pointer types
--- 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 as you've correctly identified this as a GCC 4.5 bug at
http://gcc.gnu.org/ml/libstdc++/2010-06/msg00159.html and
http://sourceware.org/bugzilla/show_bug.cgi?id=11639
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
Known to fail|4.5.0 |4.5.0 4.5.1
Summary|[4.5 Regression] wrong debug|[4.5 Regression] missing
|info for nested typedef |debug info for pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug debug/44645] [4.5 Regression] missing debug info for pointer types
--- 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()
{
Base *b = this;
Base br = *b;
}
int main()
{
Derived d;
d.foo();
Base *b = d;
}
Within Derived::foo b has type void*
Breakpoint 1, Derived::foo (this=0x7fffe5f0) at bug.cc:18
18 Base *b = this;
(gdb) ptype b
type = void *
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug c++/45341] Compiler error matching template function with array reference parameter to anonimous struct array
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45341
[Bug c++/45341] Compiler error matching template function with array reference parameter to anonimous struct array
--- 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/bugzilla/show_bug.cgi?id=45341
[Bug c++/45328] bug w/ typedefs and std::initializer_listT
--- 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
[Bug c++/45303] Compile error when not using -ftree-ter
--- 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 http://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html like (void *)Foo::foobar, it will even work with -O0. Does that cast still use the extension? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45303
[Bug c++/45303] Compile error when not using -ftree-ter
--- 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 optimisation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45303
[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict
--- 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/show_bug.cgi?id=45300
[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict
--- 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)? If not, there is no semantic difference even with a change to __restrict -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300
[Bug c/45289] gcc lacks a posix option for -std since POSIX 2008 defines special behavior
--- 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
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 there is not true? You
said
it, why is it not true? Are you recanting? Wikipedia is the place to post true
statements, it if is the truth then it should be there. Don't tell me now that
you are ashamed of what you said, are you?
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.
As with most of your comments, they are unfounded and easily refuted by
checking facts, but you're so sure you know them that you don't need to check.
As you've said before, learn to read.
Please: you and your friends keep of from removing a perfectly valid criticism
that I backed up with your statements. You think you can just keep on
removing,
but I'll just keep on putting it back. Until I get bored and take it up to
Wilkipedia. Why didn't you remove the other guy's criticism about GCC being
buggy and producing crappy code? Is his criticism better than mine? Is it
better substantiated than mine?
Wikipedia editors are our friends now? Are you paranoid?
I don't see where you are getting at. I don't want you to be the only one who
knows the truth, I want everyone to know about it. Duhh!! Why else would I
post
it on Wikipedia?? I don't want GCC to keep any secret pitfalls from anyone, is
that alright with you?
Noone wants it to be a secret, everyone in the GCC project would prefer if no
users shared your incorrect beliefs.
It claims is cdecl conformant, but even without optimizations it doesn't place
parameters on the stack as cdecl states. My bad, GCC does not guarantee cdecl
anywhere, you are right. So I'll just shut up with that.
Check your favourite reference - the Wikipedia entry on cdecl says GCC is the
de facto standard for caling conventions on Linux - so by definition what GCC
does is correct. It must be true, Wikipedia says so.
Was Microsoft wrong? No, us in the real world love it. In fact, this code:
class Color;
class Vector;
virtual func(Color c=Color(WHITE), Vector v=Vector(VECTOR_Z));
Has no workaround for in GCC. Why? Because GCC can't initialize parameters
that
are classes. MSC can. So this code (which I needed to do, no real practical
alternative), cannot be compiled in GCC. Why? Because GCC doesn't go beyond
standards. Period.
What are you talking about? You were originally talking about initializing
non-const references with temporaries. The code above would work fine, if
you'd defined Color and Vector.
class Color { public: Color(int); };
class Vector { public: Vector(int); };
const int WHITE = 0;
const int VECTOR_Z = 0;
class Idiot {
virtual void func(Color c = Color(WHITE), Vector v = Vector(VECTOR_Z));
};
GCC compiles that fine, try it.
GCC compiles that because it's valid C++.
What is your point?
Keep this up, future employers will love to see you making an idiot of yourself
so publicly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45284] sort accesses memory before first iterator
--- 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
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 used to it, I'm a mean sonofagun and I'll keep showing you why you're wrong. You're an idiot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 thought that was your mom, sorry. Good way to make a convincing argument. You've tried to turn this into a your mom argument in three replies now, but noone seems to be rising to the bait. No, the worse is being wrong and don't admit it. When we admit we learn, so I've been learning quite a lot with you guys. You didn't admit anything, so in your mind LDT read accesses a still prohibitive, and crap like that. Or did you think I would forget all the crap that you said that I shot down and you didn't admit?? Your future employers (if any!) will see that your ability to learn simple stuff is impaired. Are you confusing me with Michael? I've not said anything about LDT. What am I supposed to admit? That GCC compiles valid C++ code? That I've wasted time replying to you? That's true, but it's my weekend and I'm waiting for a GCC testsuite run to finish so I have time. You keep accusing GCC of not compiling useful C++ code, but haven't shown a valid example yet. I am happy to learn but I don't see anything worth learning from you, your opinions or your debating style. Even your trolling skills are poor, and you started so well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 got mixed up. We were discussing
the post and I didn't check the sender. There are just too many of you guys.
I'm sorry, this comment wasn't meant for you (I must be getting tired).
See, you talk crap? (I'm responding like that because that's your manner of
response, you attack and you insult and you aren't even paying attention to
what you're replying to.)
What am I supposed to admit? That GCC compiles valid C++ code?
You don't have to admit anything really. But in your comment #34 to bug #45249
you missed the point entirely and just spewed out standards. You missed the
point really, as I was saying GCC can't, and it really can't. Spewing out
standards just to explain GCC can't because insert standards here was not
really useful for that discussion. Does not make an idiot out of you though.
GCC *could* compile invalid code, if we wanted it to, but it doesn't. That's by
design, not due to accident or inability to make it work.
Several other C++ compilers don't compile it either.
The reason is because they aim to follow the relevant standards. And so that's
why I referenced the standard.
Then you claimed What a charming idea, that a compiler could become perfect
by
doing what I said it should. And that is very close to making an idiot out
of you, because you deflected without getting the background for the
conversation straight. I had to show you (again) that you failed to see that
what I say is what C99+cdecl say.
Yes, that was sarcasm, in the (apparently wrong) hope that you'd get a hint and
go away.
You keep accusing GCC of not compiling useful C++ code, but haven't shown a
valid example yet.
Yes I have. It is there on Wikipedia. The code compiled is not valid (in a
functional sense) because the programmer cannot trust the pointer difference.
Maybe at this point you get confused because you didn't type valid [according
to standards] example, but you didn't type it. So valid is open for
discussion. And I say that is valid if it returns 0x4000-0x3000=0x1000.
The ISO C and C++ standards say what's valid in this context, not you.
So there you go, now you're an idiot like Michael (well, still less, your
error
rate is much lower and of much less significance). You are an idiot because
you
don't know what valid is to everyone, you just think you do because you know
of some standard that says what is valid in a given context. I do assembly
inside my C code with MSC, is that not valid because it is not defined in
any
C standard? Nope. It is valid, no matter how much you kick and scream.
No, in the context of a compiler which tries to conform to the ISO standard,
the ISO standard is the definition of what's valid.
With the same train of thought I could talk about initializing classes as
parameters to functions as in comment #25 of bug #45249 (as another example I
posted and that you didn't see), because, again, you didn't explain what the
valid word in your text was supposed to mean. I know you mean standards, but
there is more to it. But this one does not make an idiot out of you because
valid is much harder to define here. So I'm am not in a position to spot the
level of idiocy in your comment (I'll just assume it is none). So I say
valid
(outside in the real world) and you say invalid (based on C standards), but
none of us are idiots for it.
You are welcome to use any definition of valid in your personal conversations,
but in the context of a compiler which aims to conform to the ISO standards you
don't get to decide what the definition of valid is. And this bugzilla is,
most certainly, in the context of GCC.
If you want to discuss other uses of valid or non-standard code, do it
somewhere else, such as the comp.lang.c newsgroup.
G++ doesn't compile that code because the code is invalid, and binding
non-const references to rvalues is unsafe, and C++ experts have decided that a
conforming compiler should not allow it. One reason for that is the following:
class X { int i; }
X f(X x) { return x; }
int main()
{
X x1 = f( X() );
return x.i;
}
This code is unsafe because it accesses X::i after it has been freed.
The standard says it's not allowed, and G++ implements that. You are free to
say it should be different, but noone will agree with you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- 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 libstdc++/45283 * testsuite/performance/30_threads/future/polling.cc: Replace calls to shared_future::is_ready. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- 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 libstdc++/45283 * testsuite/performance/30_threads/future/polling.cc: Replace calls to shared_future::is_ready. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- 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 DW_AT_external. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug c++/45153] DWARF DW_AT_external flag set for undefined variables
--- 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* in the same compilation unit and are *visible/accessible from outside* of it. Can't you look for DIEs which have DW_AT_external and which have a later DW_AT_specification, which completes the earlier non-defining declaration. DW_AT_specification tells you it's defined, DW_AT_external tells you it's visible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45153
[Bug libstdc++/45276] Need to document _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE
--- 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 are generated from docbook sources in libstdc++-v3/doc/xml/manual -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-13 11:50:12 date|| Summary|Need to document|Need to document |_GLIBCXX_SYNCHRONIZATION_HAP|_GLIBCXX_SYNCHRONIZATION_HAP |PENS_BEFORE |PENS_BEFORE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45276
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 clearly don't know what you're talking about. If you think the C++ language is incorrectly defined then take it up with the C++ Standard Committee, or your national standards body, not with GCC. GCC implements the C++ standard. If there's a problem with the standard, change the standard, not GCC. But the standard won't change in this respect. You cannot initialise a non-const reference with a temporary in C++, Microsoft's compiler is wrong to accept it, try Intel's compiler for confirmation if you don't believe me. Andrew already told you to read about rvalue-references, which allow you to bind a reference to a temporary, but you're too busy arguing to accept that maybe, JUST MAYBE, someone knows something you don't. So please, stop posting here and go away. Publish your ideas where someone gives a damn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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, so educating them is a good thing. But you won't do that by posting here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- 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 AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-14 00:19:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 and the other pointer points to different object. Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Bravo, well trolled. I'm subtracting 2 pointers of the same type. If you knew how to read you would have seen that p1 and p2 are of the same type. Or maybe you just don't know C, but I'm sure you can learn it so that you can be helpful to the GCC team and not waste my time. Please stop trying to use GCC, we'll all be better off. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 need the code to be cdecl compliant, that is too complicated for you and it would just confuse you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 to comment #6) Pretty pretty please: before you give out such wrong and embarassing answers please take the time to learn the standards and also take the time to learn how to read. Maybe you should practice what you preach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- 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 be open to anything, including something along the lines of ok, it is not a bug, but we will consider this as a feature request... but not even that. You opened this bug report with insults, what sort of response do you expect? GCC is too crappy and amateur for your awesome code, so I suggest you stick to better compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- 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 standard. If you want to rely on your assumptions write assembler or do not enable optimisation. (In reply to comment #13) Created an attachment (id=21453) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21453action=view) [edit] Source file (example 2) // linux (cannot use stdarg because this function does not take variable parameters and // so the compiler generates an error (shouldn't it be a warning?). Have you checked how va_start is defined? void va_start(va_list ap, parmN); ... The parameter parmN is the identifier of the rightmost parameter in the variable parameter list in the function definition (the one just before the , ...). You use *format_address as parmN, which is not an identifier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- 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. In LINUX this cannot be used in
It's Linux (or GNU/Linux) not LINUX.
format_indirect as GCC does not allow me to use vsnprintf on a function that
doesn't take variable parameters.
I explained why, see 7.15 in the C99 standard.
I tried to bypass it specifying variable
parameters for format_indirect, but of course the results are wrong because
GCC will have placed the wrong address in format_address inside
format_indirect. So, in fact, vsnprintf will have exactly the same problem
as
I had, and I would report exactly the same bug like I did.
Not if you use it correctly, which you are not doing.
void format_direct3(char* dst_buffer, int dst_buffer_size_bytes, const char*
format, ...) {
va_list va;
va_start(va, format);
vsnprintf(dst_buffer, dst_buffer_size_bytes, format, va);
va_end(va);
}
As you can see I've tried very hard to explain all details of the problem,
and
why this is a bug in GCC.
GCC claims to support C and C++. Can you point to part of either standard
which says your code is valid?
You just keep dismissing all my arguments without any justification
whatsoever.
What you're doing is not defined by the C or C++ standard.
GCC is a C and C++ compiler. Can you show where in the C or C++ standards it
says the stack must be laid out as you want?
When you did justify I just proved your arguments to be false (no disrespect
intended) in the hope that this conversation would progress.
You don't explain why I can't rely on the calling convention to ensure the
parameters will be adjacent,
Because the C and C++ standards do not make any guarantees about layout of
arguments in memory, so when using a C or C++ compiler to compile C or C++ code
you should not assume any particular layout.
and you don't explain why I can't use format to
get the address of that packed data on the stack. You just keep invoking some
standard where these 2 things are alledgedly not defined but without
materializing it (which I don't believe you can anyway!). You have not yet
shown why GCC is not required to place the parameters correctly on the stack,
and why GCC does not need to give me the true format.
The standard does not define how arguments are laid out, therefore it is
undefined.
So I'm stuck with your you can't because you can't replies and this
conversation will not progress any further, of course.
The onus is on you to show where in the C standard it says that your code is
well defined. If the standard doesn't say it, it's not portable and not well
defined.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- 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 http://en.wikipedia.org/wiki/X86_calling_conventions for a number of references on this parameter packing in the stack, one of my favorites is http://sco.com./developers/devspecs/abi386-4.pdf; where you can read in Figure 3-48: C Stack Frame how the parameters should be placed on the stack. That's a good reference. Did you see page 70? If you're not interested in writing portable code, don't blame the compiler. Anyway, that enough for me, I already spent way too much energy and time At least we can agree on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug c++/45249] Indirect variable parameters sometimes cause segmentation fault
--- 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 because of GCC's shortcommings):
class Temp {
public:
Temp(int b);
Temp(Temp t);
void operator=(Temp t);
};
void func(int a, class Temp b, int c);
func(10, Temp(20), 30); // error
ISO/IEC 14882:2003(E) 8.5.3 [dcl.init.ref] paragraph 5
This code does not compile in GCC, and so is not portable. That's shortcomming
of GCC that makes my code be not portable, not me. Its GCC's fault that code
that invokes Temp(20) as a parameter is not portable, not the programmer's
fault.
ibid.
Unfortunately, conversations like this one show that GCC will never be
perfect,
because people like you will insist that the compiler doesn't need to do what
I
said it should (even when facing the obvious references that I've posted), and
prove that page 70 is right about warning programmers not to rely on compilers
to do correct parameter placements.
What a charming idea, that a compiler could become perfect by doing what I
said it should
My personal experience is that GCC is the cause for such portability problems.
You still insist that GCC doesn't need to improve in this respect, and that
shows why GCC will never be as good as other compilers. Microsoft, for
example,
appreciates comments like mine because it helps them improve the product, but
you just want to dismiss it as bad code on my part. I know Microsoft's people
get paid to do so, but, still, I'm talking about the right mind set.
Oh, how delightfully quaint!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45249
[Bug libstdc++/45226] the difference of fstream's open() in different GCC version
--- 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 http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-3.4/classstd_1_1basic__ofstream.html#std_1_1basic__ofstreama4 Please do NOT reply with more questions about using the C++ standard library, there are lots of books and websites where you an find the information you need. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45226
[Bug libstdc++/42925] Not possible to compare unique_ptr with 0
--- 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
