[Bug c/29186] optimzation breaks floating point exception flag reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186 --- Comment #25 from Richard B. Kreckel --- (In reply to Richard Biener from comment #24) > So you're just lucky indeed ... This makes me wonder if there is still a way to trigger this. You suggest this has been fixed for the division (is there a PR or reference?) and I am not able to create a similar bug using addition, multiplication, etc. using GCC 10.
[Bug c/29186] optimzation breaks floating point exception flag reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186 --- Comment #22 from Richard B. Kreckel --- I can't reproduce this bug any more, with any of the optimization settings on x86 or x86_64 going back as far as GCC 4.9.2. Delighted to see that this has been addressed in the meantime (even without supporting that pragma.) I suppose this bug can just be closed. I don't know about 30568. (Don't understand why it's related at all).
[Bug c++/79702] New: AX_CXX_COMPILE_STDCXX([17]) does not work with GCC=7.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79702
Bug ID: 79702
Summary: AX_CXX_COMPILE_STDCXX([17]) does not work with
GCC=7.0.1
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kreckel at ginac dot de
Target Milestone: ---
This program is reduced from the C++17 conftest produced by the macro from
https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html:
#include
struct S
{
int x1 : 2;
volatile double y1;
};
S f3()
{
return {};
}
const auto [ x3, y3 ] = f3();
It fails to compile with g++ 7.0.1 20170205 on x86_64-pc-linux-gnu:
$ g++ -std=c++17 -c conftest.cpp
conftest.cpp:14:12: error: 'std::tuple_size::value' is not an integral
constant expression
const auto [ x3, y3 ] = f3();
^~
The error has something to do with , as it goes away if I comment out
the #include directive.
[Bug c++/70698] New: ICE in autoconf test for C++11 features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70698
Bug ID: 70698
Summary: ICE in autoconf test for C++11 features
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kreckel at ginac dot de
Target Milestone: ---
Created attachment 38292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38292=edit
test case
GCC 6.0.1-RC-20160415 segfaults on the attached test program which is part of
AX_CXX_COMPILE_STDCXX_11 serial version number 13:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/data/scratch/gcc-6.0.1/libexec/gcc/x86_64-pc-linux-gnu/6.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6.0.1-RC-20160415/configure --enable-languages=c,c++
--prefix=/data/scratch/gcc-6.0.1 --enable-checking=release --disable-multilib
--disable-nls
Thread model: posix
gcc version 6.0.1 20160415 (prerelease) (GCC)
$ g++ conftest.cpp
conftest.cpp:165:27: in constexpr expansion of
'cxx11::test_constexpr::strlen_c(((const char*)"1"))'
conftest.cpp:161:24: in constexpr expansion of
'cxx11::test_constexpr::strlen_c_r(((const char*)s), 0ul)'
conftest.cpp:154:29: in constexpr expansion of
'cxx11::test_constexpr::strlen_c_rconst char*)s) + 1u), (((long
unsigned int)acc) + 1ul))'
conftest.cpp:165:44: internal compiler error: Segmentation fault
static_assert(strlen_c("1") == 1UL, "");
^
0xabb5bf crash_signal
../../gcc-6.0.1-RC-20160415/gcc/toplev.c:335
0x6ed483 get_fundef_copy
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:1010
0x6ed483 cxx_eval_call_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:1453
0x6ef2af cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3556
0x6ef399 cxx_eval_conditional_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:1798
0x6ef399 cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3855
0x6f0d91 cxx_eval_store_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3123
0x6eeadc cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3633
0x6ee6c8 cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3645
0x6ee8c5 cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3672
0x6ee8c5 cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3672
0x6eda0a cxx_eval_call_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:1494
0x6ef2af cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3556
0x6f0d91 cxx_eval_store_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3123
0x6eeadc cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3633
0x6ee6c8 cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3645
0x6ee8c5 cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3672
0x6ee8c5 cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3672
0x6eda0a cxx_eval_call_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:1494
0x6ef2af cxx_eval_constant_expression
../../gcc-6.0.1-RC-20160415/gcc/cp/constexpr.c:3556
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
The last snapshot 20160410 still worked (as do all previous releases).
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #26 from Richard B. Kreckel kreckel at ginac dot de 2011-11-04 08:17:20 UTC --- (In reply to comment #25) By the way, if isn't clear already, I would be *really* curious to know which specific targets by now can't just enable the builtins, eg, their libc doesn't provide the C99 complex functions. Sadly, the libc functions aren't always correct either. But that is another story: http://sourceware.org/bugzilla/show_bug.cgi?id=13305
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #23 from Richard B. Kreckel kreckel at ginac dot de 2011-11-03
23:57:55 UTC ---
(In reply to comment #16)
Well, I guess this would be most of it:
templatetypename _Tp
std::complex_Tp
__complex_acosh(const std::complex_Tp __z)
{
return _Tp(2.0) * std::log(std::sqrt(_Tp(0.5) * (__z + _Tp(1.0)))
+ std::sqrt(_Tp(0.5) * (__z - _Tp(1.0;
}
[Sorry for my temporary absence.]
For future reference, some final remarks:
* Yes, that is a good implementation for this fallback.
It relies on __z - _Tp(1.0) not mutating the sign of __z's imag part.
* If the complex log does not do the right thing, all is lost anyways
(besides, __complex_asinh relies on it, too).
* My patch BC1 was flawed. It contains code trying to work around a ctor doing
multiplication (fixed in PR48760)
* My patch BC2 was flawed for the same reason: __z - __one doesn't preserve
the sign of __z's imag part.
Looks good. Thanks!
[Bug libstdc++/50957] New: complexT ctor drops sign of zero (sometimes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50957
Bug #: 50957
Summary: complexT ctor drops sign of zero (sometimes)
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: krec...@ginac.de
When compiling with -std=c++0x (and only then), the ctor of g++ drops the sign
of zero. (This sometimes devastates the correct choice of branch cuts in the
complex plain.) Interestingly, it doesn't happen with my mock complex class.
#include iostream
#include complex
using namespace std;
templatetypename _Tp
struct mock_complex
{
typedef _Tp value_type;
_GLIBCXX_CONSTEXPR mock_complex(const _Tp __r = _Tp(), const _Tp __i =
_Tp())
: _M_real(__r), _M_imag(__i) { }
const _Tp
real() const { return _M_real; }
const _Tp
imag() const { return _M_imag; }
private:
_Tp _M_real;
_Tp _M_imag;
};
int main()
{
mock_complexdouble z1(-0.0, 1.0);
cout signbit(z1.real()) signbit(z1.imag()) endl; // correct: 10
complexdouble z2(-0.0, 1.0);
cout signbit(z2.real()) signbit(z2.imag()) endl; // wrong: 00
}
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 Richard B. Kreckel kreckel at ginac dot de changed: What|Removed |Added See Also||http://gcc.gnu.org/bugzilla ||/show_bug.cgi?id=50957 --- Comment #11 from Richard B. Kreckel kreckel at ginac dot de 2011-11-02 08:26:51 UTC --- Paolo, I still intend to come forward with a patch for all these cases. Unfortunately, I was distracted by what I've just filed as Bug 50957.
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #5 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 07:06:57 UTC --- On 10/27/2011 11:24 AM, paolo.carlini at oracle dot com wrote: Thus, to understand and clarify why this has not been noticed so far, you are on a target which doesn't support in the underlying C library these complex functions, right? Because normally (eg, on Linux) these days we just forward to __builtin_cacosh*, the code you are touching is just a surrogate, a fallback, which doesn't get right all the special cases, NaNs, infinity. Well, I didn't notice it. Searching for bugs involving branch cut positions of inverse trig functions in a range of FOSS projects is a pet project of mine. ;-) BTW: I noticed that my patch tests if (__z.real() -0.0), which is correct, but the sign of zero looks eccentric and might potentially confuse future readers. I suggest removing it. It doesn't matter at all, anyhow.
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #7 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 21:52:08 UTC --- As soon as I find a bit of time, we can also *consistently over all those cases* use __builtin_signbit, as suggested by Gaby elsewhere. I have to double check with the middle-end people that it doesn't generate library calls for the patch to be neat. We also better double check whether the results stay correct. Thinking of it... Big Ooops! It turns out the patch makes it much better but still not entirely correct. On systems that feature a signed zero, it gives incorrect results when either * __z.real() is -0.0 and signbit(__z.imag()) * __z.real() -1.0 and __z.imag() is -0.0 The first problem can be fixed by using signbit instead of -0.0, as you proposed, but the second needs more correction. The patch BC1 I'm attaching should fix these cases, too. But this is starting to look cumbersome. We are trying to construct a formula that is continuous except on the branch cut defined in C99. Why not just use the formula mentioned in CLTL2 [0] like in patch BC2 that I'm attaching? (The branch cuts of inverse trig functinos in C99 and Common Lisp are the same.) [0] http://www-prod-gif.supelec.fr/docs/cltl/clm/node129.html#SECTION001653000
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #8 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 21:53:30 UTC --- Created attachment 25653 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25653 BC1
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #9 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 21:54:07 UTC --- Created attachment 25654 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25654 BC2
[Bug libstdc++/50880] New: __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 Bug #: 50880 Summary: __complex_acosh() picks wrong complex branch Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: krec...@ginac.de According to the C++ standard, acosh(complexT) should behave just like C99's cacosh(T complex) function. There, the branch cut is at values less than 1 along the real axis and the range of a half-strip of non-negative values along the real axis and in the interval [-i*pi,+i*pi] along the imaginary axis. The implementation in tr1/complex gets this wrong. The result returned by __complex_acosh() are all wrong in the lower complex plain. It can be easily fixed. I'm attaching a patch.
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #1 from Richard B. Kreckel kreckel at ginac dot de 2011-10-27 07:12:12 UTC --- Created attachment 25623 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25623 patch to fix the bug
[Bug c++/47585] New: remaining dependent base lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47585
Summary: remaining dependent base lookup
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: krec...@ginac.de
G++ accepts this invalid code:
template class T
struct base {
void f(void*);
};
template class T
struct derived : baseT {
derived() { f(this); } /* note: f(0) breaks g++, too */
};
struct instanced : derivedunsigned {
instanced() {}
};
See a recent discussion on news:comp.lang.c++.moderated about this:
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/ba5a7a368233a022
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #20 from kreckel at ginac dot de 2009-05-04 06:47 --- So, Joseph explained that the code should execute as expected, at least with -frounding-math as a workaround. However, with GCC 4.4 it is still not possible to write code that takes advantage of those advanced features of IEEE754, even on hardware that supports it directly. Could someone, please, set this bug's status to something less inappropriate than unconfirmed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug middle-end/30568] -ftrapping-math should prevent folding/dead code stripping of some builtins
--- Comment #5 from kreckel at ginac dot de 2009-02-15 20:09 --- (In reply to comment #4) This is an (easier) variant of PR29186. Confirmed. The difference between this bug and PR29186 is that this one here can be explained by failing to correctly treat the exception flags at compile-time (after const folding), whereas PR29186 is all about code movements that make these flags unreliable during runtime. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30568
[Bug c/39036] Decimal floating-point exception flags done wrong
--- Comment #4 from kreckel at ginac dot de 2009-01-30 22:37 --- (In reply to comment #3) From the point of view of GCC it is invalid because fenv.h and the functions it declares are not provided by GCC, but by the C library. On the other hand, one can argue that if GCC cannot guarantee that these C library functions get executed in the proper order, it should provide replacements of these functions for which it can make this guarantee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39036
[Bug c/37289] New: ICE after non-trivial conversion at assignment
I am using GCC 4.4.0 20080829 (experimental).
$ cat u.c
void f(unsigned long x);
void g(long x)
{
f((unsigned long)(-1-x)+1);
}
$ gcc -c u.c
u.c: In function 'g':
u.c:4: error: non-trivial conversion at assignment
D.2087
x
D.2087 = -x;
u.c:4: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE after non-trivial conversion at assignment
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37289
[Bug libstdc++/32422] New: Problem reading floats with exponent marker but no exponent
When reading malformed floats like 3.14e using operator, it appears like
the e character is removed from the input stream but the fact that the stream
state does not signal that something went wrong.
$ cat lcast.cpp
#include sstream
#include iostream
using namespace std;
int main()
{
stringstream buf;
buf.str(1e);
float r;
buf r;
cout float== r endl;
cout tellg()== buf.tellg() endl;
cout fail()== buf.fail() endl;
}
$ g++ lcast.cpp./a.out
float==1
tellg()==2
fail()==0
This was noticed in the context of the boost library. There,
boost::lexical_castfloat(1e) silently return 1.0, which is surprising. E.g.
a compiler would reject float x = 1e saying exponent has no digits or
something along these lines.
--
Summary: Problem reading floats with exponent marker but no
exponent
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32422
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #18 from kreckel at ginac dot de 2006-11-19 11:22 --- An idea: Would it help if feholdexcept, fetestexcept and all those standard functions accessing the status and control flags were implemented as builtins, not as extern libcalls? This probably wouldn't help against elimination of unused statements that nevertheless trigger side effects. But it would inhibit the worst cases of code reordering, I suppose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #17 from kreckel at ginac dot de 2006-11-06 22:23 ---
(In reply to comment #15)
Maybe scheduling would have the same issue. The fact that the result of the
division is not used is a red herring, though. Of course, the assumption is
that it's actually used.
For the record: Andrew was right and above statement is wrong. The standard
explicitly mandates that unused code must not be removed unless the compiler
can determine that it cannot raise an exception flag [F.8.1]:
: Concern about side effects may inhibit code motion and removal of seemingly
: useless code. For example, in
: #include fenv.h
: #pragma STDC FENV_ACCESS ON
: void f(double x)
: {
: /* ... */
: for (i = 0; i n; i++) x + 1;
: /* ... */
: }
: x + 1 might raise floating-point exceptions, so cannot be removed. And since
: the loop body might not execute (maybe 0 ³ n), x + 1 cannot be moved out of
: the loop. (Of course these optimizations are valid if the implementation can
: rule out the nettlesome cases.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #16 from kreckel at ginac dot de 2006-10-31 11:48 --- A quote from http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF: While on the subject of miscreant compilers, we should remark their increasingly common tendency to reorder operations that can be executed concurrently by pipelined computers. C programmers may declare a variable volatile to inhibit certain reorderings. A programmer's intention is thwarted when an alleged 'optimization' moves a floating-point instruction past a procedure-call intended to deal with a flag in the floating-point status word or to write into the control word to alter trapping or rounding. Bad moves like these have been made even by compilers that come supplied with such procedures in their libraries. (See _control87 , _clear87 and _status87 in compilers for Intel processors.) Operationsâ movements would be easier to debug if they were highlighted by the compiler in its annotated re-listing of the source-code. Meanwhile, so long as compilers mishandle attempts to cope with floating-point exceptions, flags and modes in the ways intended by IEEE Standard 754, frustrated programmers will abandon such attempts and compiler writers will infer wrongly that unexercised capabilities are unexercised for lack of demand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #13 from kreckel at ginac dot de 2006-10-25 07:54 --- (In reply to comment #12) It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER bug. I just discovered that it does disappear with -fno-tree-sink, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #15 from kreckel at ginac dot de 2006-10-25 13:22 --- (In reply to comment #14) Maybe scheduling would have the same issue. The fact that the result of the division is not used is a red herring, though. Of course, the assumption is that it's actually used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
-- kreckel at ginac dot de changed: What|Removed |Added Severity|enhancement |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #12 from kreckel at ginac dot de 2006-09-24 16:51 --- (In reply to comment #11) This is a TER bug then and I really doubt it can be fixed easy. It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER bug. -- kreckel at ginac dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #5 from kreckel at ginac dot de 2006-09-23 21:41 ---
(In reply to comment #3)
So this is not a bug except for the fact GCC does not implement #pragma STDC
FENV_ACCESS
According to C99, 7.6.1, you are technically right. But still: an
implementation that does not allow access to floating point flags irritates me.
Couldn't that be outright dangerous, in certain circumstances?
Consider a hypothetical train control unit:
#define FE_CRITICAL (FE_DIVBYZERO|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW)
double compute_speed(double measurement)
{
return -1./(measurement); // in reality, some rather hairy computation
}
// Adjusts speed towards nominal speed, given measurement of speed sensor.
// May decelerate, in unforeseen cases.
void control(double nominal_v, double measurement)
{
#pragma STDC FENV_ACCESS on
feclearexcept(FE_CRITICAL);
double v = compute_speed(measurement);
if (fetestexcept(FE_CRITICAL)) {
// Unexpected error: should not trust the computed speed.
decelerate();
return;
}
if (v nominal_v*1.001) {
printf(v==%f\n,v);
decelerate();
return;
}
if (v nominal_v*0.999) {
accelerate();
return;
}
}
Would you board that train if the train control unit were compiled with GCC?
The function decelerates the train if something unforeseen happens inside the
speed computation. At least it did that when it was compiled with GCC 3.3.x,
3.4.x, or 4.0.x. Now, with GCC 4.1.x, all bets are off. Also, no compiler
version seems to care to print a warning.
Having the users lulled in a false sense of safety for so long, this changed
behavior with a allusion to the standard (we need not return something
meaningful) strikes me as, excuse me, somewhat careless.
Maybe somehone can provide other suggestions how to program defensively? In
principle, the functionality used above (testing floating point flags) has been
promised since two decades (it's IEEE 754) and has been implemented in almost
every major hardware since as long. Can GNU-C not be used for such simple
things?
--
kreckel at ginac dot de changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #7 from kreckel at ginac dot de 2006-09-23 22:11 --- (In reply to comment #6) Use -frounding-math to enable FENV_ACCESS for the whole translation unit, Sorry, I fail to see what -frounding-math has to do with this. The example in comment #5 was about overflows and divisions by zero. Anyway, adding -frounding-math does not change anything in the case at hand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #9 from kreckel at ginac dot de 2006-09-23 22:58 ---
(In reply to comment #8)
I am still not entirely sure whether we are really talking about the same
problem. The original problem was that the compiler optimized assuming that the
floating point division cannot have side effects, such that the offending
division happens after the call to fetestexcept(3):
#include fenv.h
#include stdio.h
int main()
{
double x = (double)printf() + 1.0; // one
double y = (double)printf(); // zero
feclearexcept(FE_ALL_EXCEPT);
double z = x / y; // should set FE_DIVBYZERO
if (fetestexcept(FE_ALL_EXCEPT)) {
printf(flag set after call.\n);
}
printf(%f/%f==%f\n,x,y,z);
}
Neither -ftrapping-math, nor -frounding-math change anything, as long as -O1 is
turned on: The printf inside the if statement is *not* executed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] New: optimzation breaks floating point exception flag reading
See http://gcc.gnu.org/ml/gcc-help/2006-09/msg00232.html. Disassembling the code suggests that, using gcc-4.1,2, both calls to fetestexcept(3) mysteriously happened before the division when optimization is turned on. This was not the case with earlier versions of gcc, where the calls to fetestexcept(3) bracket the fdivl instruction. -- Summary: optimzation breaks floating point exception flag reading Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kreckel at ginac dot de GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #4 from kreckel at ginac dot de 2006-09-22 22:34 --- (In reply to comment #1) This is not really a bug in C99 unless you use: #pragma STDC FENV_ACCESS on But then again we don't implement that pramgma yet Okay, I was not aware of that pragma. Thank you for pointing it out. But what I find hard to grasp is why it works with previous releases. We have this library call fetestexcept(3) and with gcc 4.1 it basically stopped working. I would say this even qualifies as a regression, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug c++/27178] New: Failure to recognize template default type argument
Consider this piece of code:
template typename T class Alloc { };
template typename T, typename A = Alloc T class List { };
template template typename class class container;
typedef container List myotherlist;
This code compiles fine with gcc-3.x, gcc-4.0 and gcc-4.1 but with gcc-4.2.0
20060415 I get an type/value mismatch at argument 1 in template parameter list
for 'templatetemplateclass classtemplate-parameter-1-1 struct container
expected a template of type 'templateclass classtemplate-parameter-1-1',
got 'templateclass T, class A class List' error.
Changing the forward declaration of template class container makes it work:
template template typename, typename class class container;
This makes the default in the template type list of class List slightly
pointless.
--
Summary: Failure to recognize template default type argument
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27178
[Bug c++/26919] New: ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
The following piece of code causes an ICE at ipa-inline.c:106 as soon as
optimization is turned on. I can reproduce it using BOOST 1.32.0 and 1.33.1. It
used to work previously (at least as of GCC 3.4.3).
#include functional
#include list
#include boost/lambda/lambda.hpp
#include boost/lambda/bind.hpp
struct Device {
Device();
static std::listDevice** allDevices_;
voidinit();
static void initAll();
};
void
Device::initAll()
{
std::for_each( allDevices_-begin(), allDevices_-end(),
boost::lambda::bind( Device::init, boost::lambda::_1 ) );
}
--
Summary: ICE in cgraph_estimate_size_after_inlining caused by
boost::lambda
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug c++/26919] ICE in cgraph_estimate_size_after_inlining caused by boost::lambda
--- Comment #2 from kreckel at ginac dot de 2006-03-29 15:36 --- Created an attachment (id=11152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11152action=view) program causing ICE preprocessed with -P -E I now see that this is not vanilla boost 1.33.1 but one which contains an enhanced tuple which can accomodate up to 32 elements. Anyway, the attached preprocessed file compiles fine with older versions of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26919
[Bug c++/23345] Assembler message: symbol is already defined
--- Additional Comments From kreckel at ginac dot de 2005-08-12 21:57 --- (In reply to comment #2) This is not a gcc bug, you cannot declare a lablel in an inline-asm that is going to be exposed. Okay then, but would adding __attribute__((visibility(hidden))) to the game prevent the function from being cloned? It doesn't seem to help! I don't see any reason why the ABI calls for a clone of that function if its visibility is declared hidden. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23345
[Bug c++/23345] New: Assembler message: symbol is already defined
$ cat bug.cc EOF
struct cl_heap {
int refcount;
};
class cl_gcpointer {
public:
cl_heap* heappointer;
cl_gcpointer (const char * s);
~cl_gcpointer ()
{
if (--heappointer-refcount == 0)
delete heappointer;
}
};
struct cl_symbol {
public:
cl_symbol (const cl_gcpointer);
};
cl_symbol cl_univpoly_varname_key = (cl_symbol)variable name;
struct cl_module_destroyer {
inline cl_module_destroyer ()
{
__asm__(\nthis_symbol_is_defined_once_or_twice:);
}
};
EOF
$ g++ -O -c fatal.cc
$ g++ -O2 -c fatal.cc
/tmp/ccDX2LCa.s: Assembler messages:
/tmp/ccDX2LCa.s:152: Error: symbol `this_symbol_is_defined_once_or_twice' is
already defined
This does not happen on a ia32 platform. The bug above was distilled from CLN.
It is responsible for the package failing to build on Debian/sid
http://buildd.debian.org/fetch.php?pkg=clnver=1.1.9-4arch=ia64stamp=1123630039file=logas=raw.
It appears to happen on m68k, too:
http://buildd.debian.org/fetch.php?pkg=clnver=1.1.9-4arch=m68kstamp=1123757682file=logas=raw.
--
Summary: Assembler message: symbol is already defined
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-linux-gnu
GCC host triplet: ia64-linux-gnu
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23345
[Bug c++/23345] Assembler message: symbol is already defined
--- Additional Comments From kreckel at ginac dot de 2005-08-11 22:02 --- BTW: this is now gcc version 4.0.2 20050725 (prerelease) (Debian 4.0.1-3) on ia64, but I've seen it with gcc 4.0.1 on ia64, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23345
[Bug c++/23345] Assembler message: symbol is already defined
--- Additional Comments From kreckel at ginac dot de 2005-08-11 22:42
---
(In reply to comment #2)
This is not a gcc bug, you cannot declare a lablel in an inline-asm that is
going to be exposed.
Is there a reference of some sort? I was unable to find one with google.
You can see the issue on any target by:
struct cl_module_destroyer {
inline cl_module_destroyer ()
{
__asm__(\nthis_symbol_is_defined_once_or_twice:);
}
};
cl_module_destroyer a;
void g(void)
{
cl_module_destroyer a1;
}
Please illuminate me why this is the same situation. I can vaguely understand
how in the latter case the compiler ends up with two labels. But this appears
to be quite different from the original situation where there's only one object
to destroy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23345
[Bug c++/22005] [4.1 Regression] ICE: SSA_NAME verification failure
--- Additional Comments From kreckel at ginac dot de 2005-06-20 19:13 --- Subject: Re: [4.1 Regression] ICE: SSA_NAME verification failure On 20 Jun 2005, Ralf dot Wildenhues at gmx dot de wrote: (BTW, even with its share of bugs, CLN might be a candidate for g++ regression testing -- it has uncovered a handful of GCC (and some CLN) bugs over time. Just a thought.) Bruno hat einmal erwaehnt, dass CLN tatsaechlich fuer Regressionstests hergehalten hat, damals, als der EGCS noch von Cygnus vorangetrieben worden ist. Mal gucken, ob jemand auf Deinen Vorschlag reagiert. Und danke vielmals fuer die Muehe! Gruss -richy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug c++/22005] [4.1 Regression] ICE: SSA_NAME verification failure
--- Additional Comments From kreckel at ginac dot de 2005-06-20 22:16 --- Subject: Re: [4.1 Regression] ICE: SSA_NAME verification failure On Mon, 20 Jun 2005, Richard B. Kreckel wrote: On 20 Jun 2005, Ralf dot Wildenhues at gmx dot de wrote: (BTW, even with its share of bugs, CLN might be a candidate for g++ regression testing -- it has uncovered a handful of GCC (and some CLN) bugs over time. Just a thought.) Bruno hat einmal erwaehnt, dass CLN tatsaechlich fuer Regressionstests hergehalten hat, damals, als der EGCS noch von Cygnus vorangetrieben worden ist. Mal gucken, ob jemand auf Deinen Vorschlag reagiert. Und danke vielmals fuer die Muehe! Erhem I was saying that I'm under the impression that CLN used to be a part of the regression tests. Sorry for the German. The To:-line says [EMAIL PROTECTED] [EMAIL PROTECTED] which happens when I try to reply privately. Silly Bugzilla. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug c++/22005] [4.1 Regression] ICE: SSA_NAME verification failure
--- Additional Comments From kreckel at ginac dot de 2005-06-10 22:10 --- (In reply to comment #5) Note this code really contains some invalid inline-asm: __asm__(jmp cl_module__cl_prin_globals__ctorend); __asm__ (\n cl_module__ cl_prin_globals __dtorend :); Though unrelated: What exactly is invalid here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22005
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-24 22:49 --- (In reply to comment #22) BTW, I can't find my copy of Kahan's old Much Ado... paper. Does anyone know of a downloadable copy? I tried to google for it, but had no luck. I finally got hold of that paper. Here is an interesting passage: : the expression z + 1 should not be replaced by the ostensibly equivalent : z + (1+i0) lest the sign of zero in the imaginary part of z be reversed : wrongly. ( Generally, mixed-mode arithmetic combining real and complex : variables should be performed directly, not by first coercing the real to : complex, lest the sign of zero be rendered uninformative; [...]) Interesting. It is true, that if z=(zr,zi), then z+1 is different from z+(1,0). The latter is transformed to (zr+1,zi+0). If zi=-0, the sign in the result is reversed wrongly. The situation is no different for 1+z. In the case z-1 it doesn't really matter whether the 1 is coerced to complex or not; the result is the same. Our case 1-z is slightly differnt, though: 1-(zr,zi) = (1-zr,-zi), according to LIA-3 (1,0)-(zr,zi) = (1-zr,0-zi), imaginary part may never become -0. Conceptually, in this case we don't loose sign information by coercing 1 to complex prior to subtracting. Rather, we avoid a spurious minus sign, right? The LIA-3 choice doesn't even serve the purpose of preserving 1-z==-(z-1), because zr might become 1.0. Sigh. But this is all a consequence of the arbitrary choice of having only +0 and -0 without a concept of exact zero or undetermined sign of zero. More generally, I completely fail to understand how one can start worrying about f(conj(z))==conj(f(z)) when one is willing to permit f(z1)!=f(z2) even though z1==z2. Somebody pass me that crack pipe, please! Someone should either close this bug or file one against LIA-3. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug c++/21092] friend inaccessibility
--- Additional Comments From kreckel at ginac dot de 2005-04-18 20:19 --- (In reply to comment #1) No, the code is invalid, as Y has not been interjected yet. This is a progression and not a regression. Really? What about paragraph 11.4/7 A name nominated by a friend declaration shall be accessible in the scope of the class containing the friend declaration. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092
[Bug c++/21092] friend inaccessibility
--- Additional Comments From kreckel at ginac dot de 2005-04-18 21:04
---
(In reply to comment #3)
This sentence just says that you can't do this:
class A { private: struct I{}; };
class B { friend class A::I; };
because A::I isn't accessible in B.
Where's that snippet from? As it stands, it's out of any context whatsoever.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092
[Bug c++/21092] friend inaccessibility
--- Additional Comments From kreckel at ginac dot de 2005-04-18 21:08
---
(In reply to comment #5)
(In reply to comment #3)
This sentence just says that you can't do this:
class A { private: struct I{}; };
class B { friend class A::I; };
because A::I isn't accessible in B.
Where's that snippet from? As it stands, it's out of any context whatsoever.
Oh, sorry. Now I understand what you're referring to.
11.4/9 appears to be the relevant section in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21092
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-08 08:23 --- (In reply to comment #17) Yes, I was referring to the draft N481, but actually N490 is more recent (no changes in the area at issue) both are available from http://www.open-std.org/JTC1/SC22/WG11/docs/documents Thank you. It appeards like the current implementation is conforming. Well, the current behaviour makes perfect sense if we assume that a floating point value has exact zero imaginary part. Conceptually, now we have three zeros: -0.0, the curiously half baked mixture of +0.0 and 0.0 and also an exact zero. Crazy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-08 22:14 --- (In reply to comment #20) Thatis the mathematical question/answer. The real issue is this: * in operator-(const T, const complexT), should the imaginary part eve be touched? there are vairous ansewrs. And, yes we've been using our brains. I don't understand. What definition of touched is meant here? Of course, some sort of touching needs to be done because at least for imag(rhs)!=0 we want to flip the sign bit. | BTW: I've always tought that systems that distinguish between 0.0 and -0.0, but | not between 0.0 and +0.0 are slightly broken from a mathematical point of view. If you ask me, any system with signed zeros is broken, to start with. Actually, I'm surprised to hear that from you since I was under the impression that all numerical analysis folks have been smoking Kahan's crack pipe. :-) BTW, I can't find my copy of Kahan's old Much Ado... paper. Does anyone know of a downloadable copy? I tried to google for it, but had no luck. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-07 20:51 --- (In reply to comment #11) I think we need more careful analysis and tracking of both C99, C++ and LIA-3. Apart from looking at standards, we could also try to use our brains, right? It must be possible to answer the question whether the current behavior is right or not by analogy with real numbers, ie. simply by looking at the imaginary part alone. On systems without signed zero, there is no problem. On systems with -0.0, the code is trying to compute 0.0 - 0.0. Can that possibly be -0.0? If the answer is _no_, then this is a bug and it ought to be fixed. Period. If the asnwer is _yes_, then, well, then I'm bemazed and confused. BTW: I've always tought that systems that distinguish between 0.0 and -0.0, but not between 0.0 and +0.0 are slightly broken from a mathematical point of view. I would much rather have three zeros: two with signs and one without a sign that would have to be interpreted as having an indeterminate sign (or even complex phase). The indetermanacy of the sign could then be reliably propagated to the result in additions, like this: +0.0 + +0.0 == +0.0 +0.0 + 0.0 == 0.0 +0.0 + -0.0 == 0.0 0.0 + 0.0 == 0.0 0.0 + -0.0 == 0.0 -0.0 + -0.0 == -0.0 In such a scheme the sign carries more information than it does on my box which asymetrically cares about a - sign but not about a + sign. Sigh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-07 22:06 --- (In reply to comment #15) Well, Richard, numerical analysis is not a game, ... Right, but a logical argument is not a game. x - (z + i * w) - (x - z) + i * (-w) We cannot disregard that, I think: before implementing something else we should at least try to understand why LIA-3 mandates that. Indeed. Has that standard been released yet? What's the exact reference, and is there some public access, maybe to drafts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-05 14:01 --- (In reply to comment #7) (p.s., FWIW, I *think* log(a1) is the same for imag(a1) == -0 vs +0) Huhh? Not if real(a1) is negative. The branch cut conventionally runs along the negative real axis. For instance, C99 specifies so. In 7.3.3.2 it also specifies that there it should be continuous with the second quadrant: implementations shall map a cut so the function is continuous as the cut is approached coming around the finite endpoint fo the cut in a counter clockwise direction. At least in the absence of signs on zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] New: operator-(const T, const complexT) vs operator-(const complexT, const complexT)
Here are three ways to express complexdouble(-4.,0.): // complexdouble operator-double(const double, const complexdouble) complexdouble a1 = 1. - complexdouble(5.0, 0.0); cout a1 endl; // (-4,-0) // complexdouble operator-double(const complexdouble, const complexdouble) complexdouble a2 = complexdouble(1.0, 0.0) - complexdouble(5.0, 0.0); cout a2 endl; // (-4,0) // complexdouble operator-double(const complexdouble, const double) complexdouble a3 = complexdouble(1.0, 0.0) - 5.0; cout a3 endl; // (-4,0) In the first version, the imaginary part gets a spurious minus sign. That is quite disruptive when you consider that a1 could be the argument of a logarithm because it then ends up on the wrong side of the branch cut. While I am currently unable to track this to any standard, I would guess that the resulting imaginary part should be governed by what 0.0-0.0 is. By analogy, the first result would be wrong, unless its undefined behavior (which would be a pity). The problem is in libstdc++-v3/include/std/std_complex.h:366. I propose to change the function body to not use unary operator- in the imaginary part. I'm going to attach two analogous patches. -- Summary: operator-(const T, const complexT) vs operator- (const complexT, const complexT) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kreckel at ginac dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-04 21:39 --- Created an attachment (id=8531) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8531action=view) Avoid using operator-, version 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-04 21:40 --- Created an attachment (id=8532) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8532action=view) Avoid using operator-, version 2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20759] New: operator-(const T, const complexT) vs operator-(const complexT, const complexT)
Here are three ways to express complexdouble(-4.,0.): // complexdouble operator-double(const double, const complexdouble) complexdouble a1 = 1. - complexdouble(5.0, 0.0); cout a1 endl; // (-4,-0) // complexdouble operator-double(const complexdouble, const complexdouble) complexdouble a2 = complexdouble(1.0, 0.0) - complexdouble(5.0, 0.0); cout a2 endl; // (-4,0) // complexdouble operator-double(const complexdouble, const double) complexdouble a3 = complexdouble(1.0, 0.0) - 5.0; cout a3 endl; // (-4,0) In the first version, the imaginary part gets a spurious minus sign. That is quite disruptive when you consider that a1 could be the argument of a logarithm because it then ends up on the wrong side of the branch cut. While I am currently unable to track this to any standard, I would guess that the resulting imaginary part should be governed by what 0.0-0.0 is. By analogy, the first result would be wrong, unless its undefined behavior (which would be a pity). The problem is in libstdc++-v3/include/std/std_complex.h:366. I propose to change the function body to not use unary operator- in the imaginary part. I'm going to attach two analogous patches. -- Summary: operator-(const T, const complexT) vs operator- (const complexT, const complexT) Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kreckel at ginac dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20759
[Bug libstdc++/20759] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-04 21:42 --- Sorry, silly repost of form data. *** This bug has been marked as a duplicate of 20758 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20759
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-04 21:42 --- *** Bug 20759 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20758] operator-(const T, const complexT) vs operator-(const complexT, const complexT)
--- Additional Comments From kreckel at ginac dot de 2005-04-04 21:52
---
Subject: Re: operator-(const T, const complexT) vs
operator-(const complexT, const complexT)
I don't see how you can trigger wrong behaviour with
operator-(const complexT lhs, const T rhs):
templatetypename _Tp
inline complex_Tp
operator-(const complex_Tp __x, const _Tp __y)
{
complex_Tp __r = __x;
__r.real() -= __y;
return __r;
}
Isn't the unary operator- a necessary ingredient for the bug because it
silently changes the sign of zero?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
[Bug libstdc++/20114] New: Non-monotonic behavior of string::reserve
gromit:/tmp$ cat resize.cc
#include iostream
#include string
using namespace std;
int main()
{
string line;
for ( size_t c=8162; c8166; ++c ) {
line.reserve(c);
cout line.capacity() endl;
}
}
gromit:/tmp$ g++-3.4 -v
Lese Spezifikationen von /usr/lib/gcc/i486-linux/3.4.4/specs
Konfiguriert mit: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4
--enable-shared --with-system-zlib --enable-nls --without-included-gettext
--program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --disable-werror i486-linux
Thread-Modell: posix
gcc-Version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)
gromit:/tmp$ g++-3.4 resize.cc
gromit:/tmp$ ./a.out
8163
8163
16355
12259
Apparently, reserve/resize overallocate when called with 8164 as argument
(unless the string has been empty before). There are other such points, at
12260, 16356, 20452, 24548 and so on at each bump where a (monotonic) change in
size is intented.
--
Summary: Non-monotonic behavior of string::reserve
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kreckel at ginac dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i486-linux
GCC host triplet: i486-linux
GCC target triplet: i486-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20114
