https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164
--- Comment #15 from Nadav Har'El ---
More than 5 years later, more and more projects are discovering this bug the
hard way, and moving from std::regex to boost::regex which doesn't have this
bug - boost::regex defaults to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #21 from Nadav Har'El ---
This old problem has become a real problem in gcc 12 with a real effect on
incorrect code generation, where code that copies an object was incorrectly
"optimized" to use __builtin_memcpy() instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108296
--- Comment #2 from Nadav Har'El ---
Thanks. Interesting. So __builtin_memcpy() is simply not supposed to work
correctly for overlapping areas? I now realize that according to memcpy(3)
documentation, memcpy() is also not guaranteed to work
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Target Milestone: ---
The following trivial code, copying a string over itself moved by one byte,
shows wrong results for __builtin_memcpy() on gcc 12.2.1:
#include
int main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106087
--- Comment #1 from Nadav Har'El ---
Created attachment 53199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53199=edit
preprocessed source file which gcc saved for reporting the crash (compressed
because of bugzilla's attachment length
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Target Milestone: ---
When building the attached file, part of the open-source OSv project, in gcc
12.1.1 (on Fedora 36), I get:
during GIMPLE pass: ccp
bsd/sys/dev/hyperv/vmbus/hyperv.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003
Nadav Har'El changed:
What|Removed |Added
CC||nyh at math dot technion.ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502
--- Comment #2 from Nadav Har'El ---
Maybe you mean it is a dup of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86164 ?
But I'm not sure. I honestly don't understand the conclusion there that ".*" is
implemented recursively. Why would such a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Target Milestone: ---
Created attachment 47736
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47736=edit
Simple test code demonstrating the bug
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940
--- Comment #1 from Nadav Har'El ---
Technically speaking, std::atomic's default constructor is not marked
"constexpr" (unlike the value-taking constructor), so I'm guessing that at the
time that gcc makes the decision to have these guards, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070
--- Comment #6 from Nadav Har'El ---
Andrew, the syscall instruction may indeed be the only ABI of the Linux kernel.
But I didn't create this issue on the Linux kernel mailing list, rather on the
libgomp library's issue tracker. Looking a the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722
--- Comment #11 from Nadav Har'El ---
By the way, I think I made a mistake in my comment and
-D_GLIBCXX_INCLUDE_NEXT_C_HEADERS is not actually needed. The thing is that
header files like have:
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722
--- Comment #10 from Nadav Har'El ---
There is nothing "holy" about glibc, and nothing "broken" about wanting to
replace it (or, as Firefox did, only a part of it). Sure, the replacement needs
to be 100% compatible with glibc, and if it isn't,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722
Nadav Har'El changed:
What|Removed |Added
CC||nyh at math dot technion.ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59281
Nadav Har'El changed:
What|Removed |Added
CC||nyh at math dot technion.ac.il
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #5 from Nadav Har'El ---
Some replies to Andrew's comments above:
1. As the number of cores continue to grow, libraries will also fix malloc
scalability issues, so concurrent malloc will no longer present a problem. The
code which
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Target Milestone: ---
Multiple threads on multiple cores should be able to concurrently throw
exceptions without bothering one another. But unfortunately, it appears that in
the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070
--- Comment #4 from Nadav Har'El ---
There is a fine line between relying on "Linux" (e.g., the glibc ABI functions
as defined in LSB for example), and relying on obscure architecture-specific
tricks (like calling the syscall *instruction* in a
++
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Target Milestone: ---
std::make_exception(object) currently does this:
make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
{
try
{
throw __ex;
}
catch
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Target Milestone: ---
I've noticed a really strange phenomenon in Gcc 5.1.1 compared to Gcc 4.9.2. I
don't know if it's a bug or a feature.
Consider the
Assignee: ian at airs dot com
Reporter: nyh at math dot technion.ac.il
CC: cmang at google dot com
When one tries to build a position-independent executable (PIE or shared
object) with gccgo, the final linking stage fails. For example:
$ gccgo -pie -fpie hello.go
/usr
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
The gcc documentation for the init_priority mentions the relative ordering of
init functions with different priorities, but neglects to mention how they are
ordered with other init functions which do
: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
CC: jakub at gcc dot gnu.org
The code in libgomp/config/linux/x86/futex.h is needlessly complicated: It
contains a definition of SYS_futex, and contains two variants (x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070
--- Comment #2 from Nadav Har'El nyh at math dot technion.ac.il ---
Hi,
What was the intention behind this intentionally? As I mentioned above, I
believe the tiny performance saving of not calling the syscall() function are
minimal, because if I
++
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
Hi, right now __thread insists that the given type has a trivial destructor.
There is unfortunately no way to silence this error, even when I deliberately
want this (e.g., I know I'll call ~T() explicitly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58408
Nadav Har'El nyh at math dot technion.ac.il changed:
What|Removed |Added
CC||nyh at math
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nyh at math dot technion.ac.il
It seems that __attribute__((init_priority(...))) demands an integer constant,
and doesn't work with constant *expressions*. For example, the following
doesn't compile:
constexpr int prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59211
--- Comment #2 from Nadav Har'El nyh at math dot technion.ac.il ---
Amazing, this workaround indeed works :-) Thanks!
With the constexpr prio, indeed using prio+0 solved the problem.
For the enum class, prio::second, I can't use addition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55841
Bug #: 55841
Summary: Unexpected behavior from STL's queue
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50776
Bug #: 50776
Summary: unused object optimized out, despite having
constructor
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50776
Nadav Har'El nyh at math dot technion.ac.il changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
31 matches
Mail list logo
