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
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
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
++
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 p
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
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
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
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
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
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
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
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
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
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
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:
--- 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
--- 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
--- 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
: 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--
kreckel at ginac dot de changed:
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
--- 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
--- 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
--- 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
--- 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
: 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
--- 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
: 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
++
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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
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
--- 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
--- 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
--- 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
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
59 matches
Mail list logo
