--- Comment #7 from eric-bugs at omnifarious dot org 2008-12-28 11:21
---
I've been meaning to revisit this bug with a recent version of gcc. And, in
fact it still happens with gcc 4.3.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11211
oduct: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric-bugs at omnifarious dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
--- Comment #4 from eric-bugs at omnifarious dot org 2009-05-20 19:17
---
Ahh, OK. I hunted a bit to find something like that, but didn't find it.
Thank you.
I now have a slightly different bug, which is a mild inadequate optimization
bug. :-) I'll cut it down to size an
--- Comment #5 from eric-bugs at omnifarious dot org 2009-05-20 19:39
---
This code:
#include
#include
inline uint64_t byteswap_64(const uint64_t x)
{
return __builtin_bswap64(x);
}
inline uint32_t byteswap_32(const uint32_t x)
{
return __builtin_bswap32(x);
}
extern void
--- Comment #7 from eric-bugs at omnifarious dot org 2009-05-20 20:22
---
I've been playing around a bit more, and I've noticed that gcc in general does
not do a spectacular job of optimizing bitwise operations of any kind.
Some kind of general framework for tracking the mo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50087
eric-bugs at omnifarious dot org changed:
What|Removed |Added
CC||eric-bugs at
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric-bugs at omnifarious dot org
Target Milestone: ---
This code will not compile with gcc trunk on compiler explorer. But it works
with gcc 8.2 on that some site. I'm worried
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
--- Comment #2 from eric-bugs at omnifarious dot org ---
Also, this works in clang 6.0 (with --std=c++17), but not gcc 8.2:
#include
constexpr int ce_strlen(char const *s)
{
int i = 0;
while (s[i]) ++i;
return i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
--- Comment #4 from eric-bugs at omnifarious dot org ---
Should I file a new bug with my new comment in it? I should probably test
against a trunk with your change in it first.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric-bugs at omnifarious dot org
Target Milestone: ---
I'm trying to construct profile tags based on __PRETTY_FUNCTION__ at compile
time while making minimal use of preproc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #1 from eric-bugs at omnifarious dot org ---
Godbolt link: https://godbolt.org/z/gHnb-G
Also, my attempt to simplify this failed because clang will not consider
arguments to constexpr functions to be constexpr. Which, IMHO, is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #3 from eric-bugs at omnifarious dot org ---
Ahh, I guess that does make sense. Oh, well. I guess I'm stuck using template
arguments in place of function arguments in some cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #4 from eric-bugs at omnifarious dot org ---
Given the new way of looking at things prompted by the correction of my
erroneous idea, I've rethought how to simplify this, and the simplification
does work in gcc 8.2, and I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
--- Comment #5 from eric-bugs at omnifarious dot org ---
Here is the problem, reduced to the simplest expression I could make:
-
template
struct test_template {
static int size() { return x; }
};
constexpr int ce_strlen(char const *s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87399
eric-bugs at omnifarious dot org changed:
What|Removed |Added
CC||eric-bugs at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87381
eric-bugs at omnifarious dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87399
--- Comment #3 from eric-bugs at omnifarious dot org ---
*** Bug 87381 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
eric-bugs at omnifarious dot org changed:
What|Removed |Added
CC||eric-bugs at
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric-bugs at omnifarious dot org
Target Milestone: ---
The following code works fine when compiled this way:
g++ -std=c++20 -march=znver2 -static -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
eric-bugs at omnifarious dot org changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108337
--- Comment #5 from eric-bugs at omnifarious dot org ---
(In reply to Andrew Pinski from comment #4)
> Yes it affects every function. There might be another way to use attribute
> to specific that only main needs this treatment. Or bett
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric-bugs at omnifarious dot org
Target Milestone: ---
Created attachment 54236
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54236&action=edit
Preprocessed C++ code that generates unneeded assemb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #1 from eric-bugs at omnifarious dot org ---
Created attachment 54237
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54237&action=edit
Assembly file containing _start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #2 from eric-bugs at omnifarious dot org ---
Created attachment 54238
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54238&action=edit
Assembly output from compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108361
--- Comment #6 from eric-bugs at omnifarious dot org ---
Technically, I suppose it is. I do reference those things in the original code.
:-)
But it is sort of annoying to get the error when I can just edit the assembly
and clip out the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316
--- Comment #55 from eric-bugs at omnifarious dot org ---
C++ may get an ABI change one of these days. It needs one in order to have a
properly efficient unique_ptr. Since that ABI change would involve who calls
destructors and C doesn't
++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric-bugs at omnifarious dot org
Target Milestone: ---
This code https://godbolt.org/z/jeYGcr5sv still generates all the exception
handling code. It treats the assume attribute more like 'likely' than 'assume
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric-bugs at omnifarious dot org
Target Milestone: ---
I would like a few things added to inline assembly support.
The first is I would very much like to be able to use templates to generate
inline assembly.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115728
--- Comment #2 from eric-bugs at omnifarious dot org ---
(In reply to Richard Biener from comment #1)
> I think there's (pending?) support to allow the asm text to be generated by
> constexpr evaluation. Not sure if that will hel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115728
--- Comment #4 from eric-bugs at omnifarious dot org ---
(In reply to ak from comment #3)
> The constexpr asm support is in trunk. It supports templates.
>
>
> >The second is I want finer grain control over marking me
30 matches
Mail list logo
