https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118975
--- Comment #1 from Nate Eldredge ---
I should have said, credit to StackOverflow user anol for finding this.
https://stackoverflow.com/questions/79457581/gcc-undef-leads-to-cannot-find-entry-symbol-start-defaulting-to-x/79457825#79457825
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
When the `-undef` option is given to gcc for a command that involves linking,
the option is passed to the linker as well as the compiler. This makes no
sense as `-undef` should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118927
--- Comment #6 from Nate Eldredge ---
After some brief digging, it seems like the problem is that
`cxx_printable_name_internal` can be called recursively by `lang_decl_name'
(via `announce_function'). This is bad because, with its static ring b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118927
--- Comment #5 from Nate Eldredge ---
Oh, it's actually triggered by the compilation of a-foo.ii itself, but the
gcm.cache has to have previously been created.
The gcm.cache is too large to post as an attachment, but I can share it another
way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118927
--- Comment #4 from Nate Eldredge ---
Note for testing that the compiler doesn't crash when compiling only
bits/std.cc, or when a-std.ii and a-foo.ii are concatenated into a single file.
It seems to be important that they are passed as separate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118927
--- Comment #3 from Nate Eldredge ---
Created attachment 60527
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60527&action=edit
stderr output from compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118927
--- Comment #2 from Nate Eldredge ---
Created attachment 60526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60526&action=edit
Preprocessor output for std.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118927
--- Comment #1 from Nate Eldredge ---
Created attachment 60525
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60525&action=edit
Preprocessor output for foo.cc
ty: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Created attachment 60523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60523&action=edit
Main source file foo.cc
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
With all versions of `gcc -O3` on godbolt, the following C++ code
struct A {
char c;
int l;
};
A clear_padding(A x) {
__builtin_clear_padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #7 from Nate Eldredge ---
@Jonathan: Done,
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640119.html (sorry, may
not be linked to original threads).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #5 from Nate Eldredge ---
Oh wait, disregard that last, I realized that I only applied one of the two
patches. Let me try again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #4 from Nate Eldredge ---
@Jonathan: I think that patch set is on the right track, but it has some other
serious bugs. For one, __atomic_wait_address calls __detail::__wait_impl with
__args._M_old uninitialized (g++ -O3 -Wall catche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #2 from Nate Eldredge ---
This bug is still present. Tested and reproduced with g++ 13.1.0 (Ubuntu
package), and by inspection of the source code, it's still in the trunk as
well.
Encountered on StackOverflow:
https://stackoverflow
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Compile the following with gcc 14.0.0 20230723 on aarch64 with -O3:
#include
void CSI2toBE12(uint8_t* pCSI2, uint8_t* pBE, uint8_t* pCSI2LineEnd)
{
while (pCSI2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527
Nate Eldredge changed:
What|Removed |Added
CC||nate at thatsmathematics dot
com
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
gcc misses an optimization (or in some sense deoptimizes) by using a
call-preserved register to save a trivial constant across a function call.
Source code
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Compiling the following code on AArch64 with -O2 or -O3:
typedef unsigned long u64x2 __attribute__((vector_size(16)));
u64x2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97473
--- Comment #2 from Nate Eldredge ---
Possibly related to bug 84877 ?
: wrong-code
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Created attachment 49394
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94196
Nate Eldredge changed:
What|Removed |Added
CC||nate at thatsmathematics dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94015
--- Comment #4 from Nate Eldredge ---
Comment on attachment 47959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47959
gcc10-pr94015.patch
I'm not qualified to opine on the proposed fix, but just wanted to note that,
as I mentioned above,
: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
CC: dmalcolm at gcc dot gnu.org, jakub at gcc dot gnu.org,
law at
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Created attachment 47937
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47937&action=edit
Reduced testcase
24 matches
Mail list logo
