ult 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
GC
--- 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 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 gua
gnedTo: 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 prag
--- 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 tha
--- 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
--- 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
--
kreckel at ginac dot de changed:
What|Removed |Added
Severity|enhancement |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
nic 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
MED
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=8531&action=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=8532&action=view)
Avoid using operator-, version 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758
MED
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 complex&) vs
operator-(const complex&, const complex&)
I don't see how you can trigger wrong behaviour with
operator-(const complex &lhs, c
--- 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 insta
--- 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 possi
--- 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 disregar
--- 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/SC
--- 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 complex&), should the imaginary
> part eve be touched?
&g
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-
--- 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
--- 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
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 su
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
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
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #1 from Richard B. Kreckel 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=50880
--- Comment #5 from Richard B. Kreckel 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #7 from Richard B. Kreckel 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 mi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #8 from Richard B. Kreckel 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 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=50957
Bug #: 50957
Summary: complex ctor drops sign of zero (sometimes)
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
Richard B. Kreckel changed:
What|Removed |Added
See Also||http://gcc.gnu.org/bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #23 from Richard B. Kreckel 2011-11-03
23:57:55 UTC ---
(In reply to comment #16)
> Well, I guess this would be most of it:
>
> template
> std::complex<_Tp>
> __complex_acosh(const std::complex<_Tp>& __z)
> {
> re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880
--- Comment #26 from Richard B. Kreckel 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
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++
As
++
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&action=edit
test case
GCC 6.0.1-RC-20160415 segfaults on the attached test program which
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
--- 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 shar
ildd.debian.org/fetch.php?&pkg=cln&ver=1.1.9-4&arch=m68k&stamp=1123757682&file=log&as=raw>.
--
Summary: Assembler message: symbol is already defined
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
--- 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 c
--- 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
rity: 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
--- 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=11152&action=view)
program causing ICE preprocessed with -P -E
I now see that this is not vanilla boost 1.33.1 but one which cont
--- 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
dec
--- 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 accessibl
--- 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;
--- 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
--- 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
--- 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++ regress
--- 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.o
--- 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.
--
--- 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
--- 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
--- 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 ag
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
59 matches
Mail list logo
