--- Comment #2 from ddenisen at altera dot com 2008-11-20 14:57 ---
I searched through all the options in -O2 that are not in -O1 and found that
only one triggers the problem: -fstrict-aliasing.
To summarize, g++ -m32 -O1 a.ii does not cause the problem but g++ -m32 -O1
-fstrict
--- Comment #3 from ddenisen at altera dot com 2008-11-20 15:10 ---
This could be a duplicate of 35643.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ddenisen at altera dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from ddenisen at altera dot com 2008-11-19 23:57 ---
Created an attachment (id=16726)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16726action=view)
Compile with g++ -m32 -O2 a.ii to reproduce the crash
The source code that shows the problem.
--
http
--- Comment #4 from ddenisen at altera dot com 2008-06-27 20:34 ---
Here's the answer to my question (in case somebody else has the same problem):
You have to use -fPIC for compiling the executable itself (but not the shared
objects) to fix the symbol resolution problem described here
--- Comment #6 from ddenisen at altera dot com 2008-03-10 14:14 ---
Thank you everybody for the feedback. I'm setting the bug to fixed.
--
ddenisen at altera dot com changed:
What|Removed |Added
: unassigned at gcc dot gnu dot org
ReportedBy: ddenisen at altera dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35499
: Documentation for -fPIC/-fpic/-fpie is not clear
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ddenisen at altera dot
--- Comment #3 from ddenisen at altera dot com 2008-03-07 19:43 ---
I did read How to write Shared Libraries and re-read PIC section a couple of
times. Could you please clarify what am I missing here?
If symbol resolution is already controlled separately, what's the flag? I
couldn't
--- Comment #2 from ddenisen at altera dot com 2008-03-07 19:45 ---
But DSOs still work if I don't use PIC. Why is that?
Why would anybody want to create position-independent executable? What are the
advantages and disadvantages?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #4 from ddenisen at altera dot com 2008-03-07 20:11 ---
I am still learning about linking and loading and I can't guess why non-PIC
DSOs would work on x86 but not on x86_64. Could you please explain briefly.
This is all very useful information that I couldn't find anywhere
is incorrect
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ddenisen at altera dot com
http://gcc.gnu.org/bugzilla
--- Comment #5 from ddenisen at altera dot com 2008-01-31 16:13 ---
@emph{Note:} there may be no value to @option{-finline-limit} that results
in default behavior.
That's also not user-friendly. When it is changed, it is not clear what is
more aggressive inlining and what
--- Comment #2 from ddenisen at altera dot com 2008-01-31 15:59 ---
(In reply to comment #1)
-finline-limit=N should be deprecated. It is an alias for --param
max-inline-insns-single=N/2 --param max-inline-insns-auto=N/2.
There is no real default, instead the defaults for max
--- Comment #4 from ddenisen at altera dot com 2008-01-31 16:12 ---
@emph{Note:} there may be no value to @option{-finline-limit} that results
in default behavior.
That's also not user-friendly. When it is changed, it is not clear what is
more aggressive inlining and what
--- Comment #7 from ddenisen at altera dot com 2008-01-31 16:40 ---
If the default behaviour has to stay, then I think the option should be
removed. Having no option is better than having an option with an
unreproducible default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35042
16 matches
Mail list logo
