[Bug libstdc++/104161] Potential Security Vulnerability: remove_all and symbolic link

2022-01-26 Thread jistone at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104161 Josh Stone changed: What|Removed |Added CC||jistone at redhat dot com --- Comment #5

[Bug target/82041] New: Windows i686 should not return float aggregates in ST0

2017-08-30 Thread jistone at redhat dot com
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jistone at redhat dot com Target Milestone: --- Target: i686-w64-mingw32 This is nearly a clone of bug 82028, but it's less clear to me if it's actually a real

[Bug c/82028] Windows x86_64 should not pass float aggregates in xmm

2017-08-29 Thread jistone at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 --- Comment #1 from Josh Stone --- Fedora's mingw-gcc also produces code passing through xmm0: : 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: f2 0f 11 45 10 movsd

[Bug c/82028] New: Windows x86_64 should not pass float aggregates in xmm

2017-08-29 Thread jistone at redhat dot com
Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jistone at redhat dot com Target Milestone: --- Given this input foo.c: #include typedef struct { double x; } Foo; Foo foo(Foo f) { f.x = fabs(f.x); return f; } mingw-gcc produces code that uses XMM0

[Bug middle-end/79665] gcc's signed (x*x)/200 is slower than clang's

2017-02-21 Thread jistone at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79665 --- Comment #3 from Josh Stone --- I'm using just -O3, and then I compared effects with and without -fwrapv to figure out what's going on. Clang is only faster without -fwrapv. With -march=native on my Sandy Bridge, a few instructions are

[Bug c/79665] New: gcc's signed (x*x)/200 is slower than clang's

2017-02-21 Thread jistone at redhat dot com
-280798073 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jistone at redhat dot com Target Milestone: --- Created attachment 40809 --> https://gcc.gnu.org/bugzi

[Bug c++/68281] New: '&&' is checked in reverse and reads an uninitialized value

2015-11-10 Thread jistone at redhat dot com
: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jistone at redhat dot com CC: fche at redhat dot com, law at redhat dot com, mark at gcc dot gnu.org Target Milestone: --- Created attachment 36683 --> https://

[Bug c++/68281] '&&' is checked in reverse and reads an uninitialized value

2015-11-10 Thread jistone at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281 --- Comment #1 from Josh Stone --- I suspect this may actually be acceptable, NOTABUG, because I can't think of any uninitialized data that would make the effective behavior different than if it had been checked in the proper order. Both

[Bug c++/68281] '&&' is checked in reverse and reads an uninitialized value

2015-11-10 Thread jistone at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281 --- Comment #2 from Josh Stone --- This may also be significant: bool base_query::get_number_param(literal_map_t const & params, interned_string k, long & v) { int64_t value; bool present =

[Bug c++/68281] '&&' is checked in reverse and reads an uninitialized value

2015-11-10 Thread jistone at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68281 Josh Stone changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug web/56544] New: documentation for __cplusplus is out of date

2013-03-05 Thread jistone at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56544 Bug #: 56544 Summary: documentation for __cplusplus is out of date Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug debug/49167] dwarf marker for function return instruction

2011-06-03 Thread jistone at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49167 Josh Stone jistone at redhat dot com changed: What|Removed |Added CC||jistone at redhat