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 #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
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:
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 (bool x)
{
const std::string s = (x ? "x" : "y");
const Foo = get_foo_by_name(s);
return f;
}
But if get_foo_by_name() has the
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lopresti at gmail dot com
Target Milestone: ---
#include
struct Foo;
extern Foo _foo_by_name(const std::string );
const Foo (bool x)
{
const Foo = get_foo_by_name(x ? "x" : "y");
retur
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=95244
--- Comment #2 from Patrick J. LoPresti ---
Done (https://github.com/google/sanitizers/issues/1253). Thanks.
: 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
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
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
Patrick J. LoPresti changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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=edit
Minimal test case for skylake-avx
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
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
++
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
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
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,
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
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=35968
Patrick J. LoPresti lopresti at gmail dot com changed:
What|Removed |Added
CC||lopresti
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=33135action=edit
Source file demonstrating bug with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
--- Comment #48 from Patrick J. LoPresti lopresti at gmail dot com ---
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
--- 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
23 matches
Mail list logo
