Assignee: unassigned at gcc dot gnu.org
Reporter: sorganov at gmail dot com
Target Milestone: ---
GCC 5.4.0 optimizes the following code to empty function, when in fact the code
does clear 'count' bytes starting from 'buf' (it looks strange as it's a
simplified version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83768
--- Comment #2 from Sergey Organov ---
4.8.3 doesn't have the issue, and I don't have fast access to any 4.9.
So presumably it has been fixed between 5.4.0 and 5.4.1... It'd still be nice
to know if there is some optimization switch in 5.4.0 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83768
--- Comment #4 from Sergey Organov ---
Well, except how one can be sure the cause is actually fixed and not just
[temporary?] hidden, if we only have the fact that it works fine in GCC 6+?
No objection to closing this though, provided no one is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
Sergey Organov changed:
What|Removed |Added
CC||sorganov at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #4 from Sergey Organov ---
"WONTFIX: The problem described is a bug which will never be fixed." sounds
very different from "nobody is interested in fixing it but but patches are
welcome". No?
Anyway, setting RESOLVED WONTFIX on an I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #6 from Sergey Organov ---
Contrary to the rationale for closing this bug, the option -freg-struct-return
seems to be supported and does work fine in some cases, see below. What do I
miss?
$ cat struct.c
typedef struct { int i; } T;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #8 from Sergey Organov ---
I'm trying to upgrade from 3.4.4 to 5.2.0, and I used -freg-struct-return for
years with 3.4.4 with no issues. Not that there is huge amount of code that
actually uses functions returning structures, but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #15 from Sergey Organov ---
Eric, thanks a lot for taking care of the issue!
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sorganov at gmail dot com
Target Milestone: ---
When compiling C code, GCC generates out-of-line copy of any inline function
that also happens to be a GCC builtin, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
Sergey Organov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
Sergey Organov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
--- Comment #5 from Sergey Organov ---
Thanks, but my particular problem is that I do want nice GCC builtin when it is
available, and I want generic inline implementation, rather than function call,
when GCC builtin is not available.
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sorganov at gmail dot com
Target Milestone: ---
g++ at version 5.2.1 for sparc-elf misses proper support for attribute
init_priority: resulting ".ctors" section does not hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68408
--- Comment #7 from Sergey Organov ---
Eric, thank you very much for the quick fix!
I confirm it is fixed on sparc-elf-g++ (GCC) 5.2.1 20151119.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845
--- Comment #16 from Sergey Organov ---
I confirm it is fixed on sparc-elf-gcc (GCC) 5.2.1 20151119.
Thanks one more time!
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sorganov at gmail dot com
Target Milestone: ---
g++ 5 produces initialization for the following case using static constructor,
while earlier versions of g++ as well as gcc 5 in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
--- Comment #6 from Sergey Organov ---
For reference, the work-around for the problem is __attribute__((gnu_inline)),
i.e., effectively turning inlining mode back to pre-c99.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
--- Comment #8 from Sergey Organov ---
That's exactly the problem: why builtins are (implicitly) declared "extern
inline" in C99 compilation mode? It seems logical to rather declare them
"inline" in this mode.
Overall, even though my own issue
18 matches
Mail list logo
