--- 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
--- 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++ -m
--- 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=16726&action=view)
Compile with "g++ -m32 -O2 a.ii" to reproduce the crash
The source code that shows the prob
ster used to get struct information
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://g
--- 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
--- 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 |
--- 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 fin
--- 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.c
--- 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 f
: 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
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ddenisen at altera dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35499
--- 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
--- 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" inl
--- 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" inl
--- 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 defa
e-limit 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.or
16 matches
Mail list logo
