--- Comment #26 from lopresti at gmail dot com 2007-02-01 02:17 ---
I found this PR because I tried calling what() on a bad_alloc, was surprised by
what I got, and did a search. This is my perspective as a random end user;
make of it what you will.
I think "std::bad_alloc&q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
--- Comment #12 from Patrick J. LoPresti ---
(In reply to Anders Kaseorg from comment #11)
> (In reply to Patrick J. LoPresti from comment #10)
> > Complexity: Linear on average.
> >
> > It is not obvious (to me) what distribution the "on averag
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
Created attachment 48265
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48265&action=edit
Minimal test case for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
Patrick J. LoPresti changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
--- Comment #5 from Patrick J. LoPresti ---
(In reply to Andrew Pinski from comment #4)
>
> Note this is true even without using intrinsics really. You can get the
> same behavior you are seeing with using standard C code.
Yes, which is one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94587
--- Comment #8 from Patrick J. LoPresti ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Patrick J. LoPresti from comment #5)
> > I did not use -ffp-contract=fast nor -funsafe-math-optimizations nor
> > -ffast-math. Yet the statemen
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
I still compile GCC on Red Hat Enterprise Linux 5. It is an EoL platform, so
maybe you do not care... But the only problem (introduced with GCC 10) is the
lack of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95244
--- Comment #2 from Patrick J. LoPresti ---
Done (https://github.com/google/sanitizers/issues/1253). Thanks.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
Test program:
---
#include
#include
char buf1[256];
void append(const char *s)
{
std::strncat(buf1, s, sizeof(buf1) - strlen(buf1) - 1);
}
void doit(int err
++
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
Test case:
#include
__float128 doit()
{
return FLT128_MAX;
}
Compile with "g++ -std=c++11" to get the error:
/tmp/quadmath.cc: In function \u2018__float128 doit()\u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87274
--- Comment #3 from Patrick J. LoPresti ---
Yes, is an extension. But it would be nice, IMO, if it were a
standard-compatible extension.
So this is, as you say, a feature request somehow to enable quad-precision
literals in standard compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434
Patrick J. LoPresti changed:
What|Removed |Added
CC||lopresti at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #14 from Patrick J. LoPresti ---
D Hugh Redelmeier in comment 12 is mistaken... memcpy is a reserved identifier
(see e.g. http://stackoverflow.com/a/23841970), so the user cannot legally
redefine it.
That said, this is clearly a real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #16 from Patrick J. LoPresti ---
Well, Valgrind itself is another real-world example. Tools like Valgrind cannot
distinguish invalid memcpy() calls by the programmer from invalid memcpy()
calls emitted by GCC.
You can, of course, red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
Patrick J. LoPresti changed:
What|Removed |Added
CC||lopresti at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #48 from Patrick J. LoPresti ---
Was this ever fixed? I do not see any mention of it in
https://gcc.gnu.org/gcc-4.9/changes.html nor 4.8/changes.html nor
4.7/changes.html nor...
In any event, "suspended" seems like the wrong status f
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Created attachment 33135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33135&action=edit
Source file demonstrating bug with ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #22 from Patrick J. LoPresti ---
I disagree that bug 108296 is a duplicate. That bug requires code that, at
least arguably, invokes undefined behavior. See e.g.
https://stackoverflow.com/q/7292862/ and https://stackoverflow.com/q/6107
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
#include
struct Foo;
extern Foo &get_foo_by_name(const std::string &name);
const Foo &bug(bool x)
{
const Foo &f = get_foo_by_name(x ? "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
--- Comment #2 from Patrick J. LoPresti ---
Um... OK...
So I have to "correct" my code like so:
const Foo &bug(bool x)
{
const std::string s = (x ? "x" : "y");
const Foo &f = get_foo_by_name(s);
return f;
}
But if get_foo_by_name() has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109671
--- Comment #3 from Patrick J. LoPresti ---
(In reply to Andrew Pinski from comment #1)
> There is no way for GCC to know that get_foo_by_name does not store the
> argument into what is returned so it warns about this case ...
To summarize:
GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #29 from Patrick J. LoPresti ---
(In reply to Jakub Jelinek from comment #27)
>
> No, that is not a reasonable fix, because it severely pessimizes common code
> for a theoretical only problem.
The very existence of (and interest in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
--- Comment #17 from Patrick J. LoPresti ---
Are all of the "duplicate" bugs also fixed by this change?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #64 from Patrick J. LoPresti ---
The C (and POSIX) standards have had "restrict" on the arguments to memcpy()
since C99. So calling it with overlapping arguments is undefined behavior and
always has been.
This bug should be trivial t
24 matches
Mail list logo
