Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron_sami_abassi at hotmail dot com
Target Milestone: ---
When initializing an auto variable from a function identifier, GNU C++ is
incorrectly defining a new
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron_sami_abassi at hotmail dot com
Target Milestone: ---
Created attachment 44010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44010&action=edit
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500
--- Comment #2 from ASA ---
(In reply to Jonathan Wakely from comment #1)
> This is not a valid bug report, see https://gcc.gnu.org/bugs/ for what we
> require.
>
> (In reply to ASA from comment #0)
> > When initializing an auto variable from a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85500
--- Comment #3 from ASA ---
> No, that's not valid as a function declaration.
Right, it's:
auto function_name( params ... );
Again, I should have slept before posting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509
--- Comment #1 from ASA ---
I should add that without the static storage duration specifier even without
const specified, it does inline the function invocation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509
--- Comment #3 from ASA ---
(In reply to Richard Biener from comment #2)
> The issue is you fail to make PerformQuickly and PerformSafely const and GCC
> doesn't have local analysis to promote it so and IPA analysis is too late
> for that since i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509
--- Comment #5 from ASA ---
> > I would expect this is likely true for any non-const static duration
> > function pointer, not just the case when the auto type specifier is used,
> > but I have not confirmed it.
>
> But it is the case for any no
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron_sami_abassi at hotmail dot com
Target Milestone: ---
Created attachment 44269
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44269&action=edit
Source code which demonstrates the optimization problem
GCC d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #1 from ASA ---
Created attachment 44270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44270&action=edit
Assembly output from GCC 7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #2 from ASA ---
Created attachment 44271
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44271&action=edit
Assembly output from clang++ 5.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #3 from ASA ---
Comment on attachment 44271
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44271
Assembly output from clang++ 5.0.0
clang++ -O -S gccbug.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #4 from ASA ---
Comment on attachment 44270
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44270
Assembly output from g++ 7.3.0
g++ -O -S gccbug.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #6 from ASA ---
(In reply to Andrew Pinski from comment #5)
> Try renaming main first. Gcc knows that main is only called once ever so
> gcc's inling heuristics are different inside main.
Same result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
ASA changed:
What|Removed |Added
Attachment #44269|0 |1
is obsolete||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
ASA changed:
What|Removed |Added
Attachment #44270|0 |1
is obsolete||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
ASA changed:
What|Removed |Added
Attachment #44271|0 |1
is obsolete||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #11 from ASA ---
(In reply to Richard Biener from comment #7)
> When you rename main() to foo() the calls are inlined. GCC doesn't inline
> them
> into main() because it knows they are executed exactly once which means they
> are col
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #12 from ASA ---
I see what you're saying now.
Indeed I compiled it without a main function with
g++ -O -S -c gccbug.cpp
and it does expand DisplayViewType inline.
Thank you for clarifying the context of the optimization issue, g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
ASA changed:
What|Removed |Added
Attachment #44276|0 |1
is obsolete||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
ASA changed:
What|Removed |Added
Attachment #44277|0 |1
is obsolete||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
ASA changed:
What|Removed |Added
Attachment #44278|0 |1
is obsolete||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #16 from ASA ---
Please have a look at the new attachments (3) which demonstrate a contrast in
the heuristic determination. Acknowledging that the first method uses two
different functions and the second method uses the same function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #17 from ASA ---
It would seem that the heuristics problem has something to do with the same
function being called more than once from main.
I conducted the following experiments:
* Repeating the call to DisplayView1Type
* Commentin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #18 from ASA ---
Eventually this optimization problem can start to have severe implications.
Consider the contrasting Assembly output of GNU C++ versus LLVM C++ in the
following case:
Original source code:
https://github.com/ASA1976
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
ASA changed:
What|Removed |Added
Version|7.3.0 |8.1.1
--- Comment #19 from ASA ---
Regarding the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86141
--- Comment #20 from ASA ---
Update:
This only seems to happen when the invocation occurs at different points from
within the main function. To clarify, if one has a loop in main and only
invokes the inline function from within the loop, it wil
26 matches
Mail list logo
