http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39578
--- Comment #4 from John E. / TDM tdragon at tdragon dot net ---
I can confirm this has been fixed. Sorry for not doing so sooner.
--- Comment #14 from tdragon at tdragon dot net 2010-04-23 00:05 ---
This affects a *ton* of code in the wild. Can we at least get a command line
flag like -fno-emit-inline-dllexports?
--
tdragon at tdragon dot net changed:
What|Removed |Added
--- Comment #10 from tdragon at tdragon dot net 2009-04-02 23:57 ---
This is the exact same behavior as is present in the most recent MinGW stable
release of GCC (3.4.5-20060117-3), and will be present in any release which
uses Danny's throwing-exceptions-from-DLLs-even-with-a-static
for dllimport vtables
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tdragon at tdragon dot net
GCC build triplet
--- Comment #14 from tdragon at tdragon dot net 2009-03-29 15:30 ---
I have just filed PR39578, the cause of which may be related to this PR or its
fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
--- Comment #9 from tdragon at tdragon dot net 2009-01-02 14:23 ---
That patch seems to work fine, and I haven't seen any unwarranted errors
relating to static data members so far. Thank you very much for tracking this
down!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
--- Comment #7 from tdragon at tdragon dot net 2008-11-02 00:54 ---
C'mon, folks! Any chance of getting this fixed?
--
tdragon at tdragon dot net changed:
What|Removed |Added
--- Comment #6 from tdragon at tdragon dot net 2008-10-09 22:57 ---
Ping! Any ideas on this bug?
--
tdragon at tdragon dot net changed:
What|Removed |Added
Known
--- Comment #5 from tdragon at tdragon dot net 2008-09-20 17:57 ---
Any news or thoughts on this bug? (*Ping*)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
--- Comment #3 from tdragon at tdragon dot net 2008-08-12 02:13 ---
As of r138967 pulled down today from the 4.3 branch, this bug is in fact still
present. Shell session follows.
g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3-svn/configure --prefix=/mingw
: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tdragon at tdragon dot net
GCC build triplet: mingw32
GCC host triplet: mingw32
GCC target triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
--- Comment #1 from tdragon at tdragon dot net 2008-06-27 17:09 ---
I have also discovered that this bug is *not* present in the MinGW 4.2.1 TP (or
in MinGW 3.4.5), but is present in unofficial builds of GCC 4.3.1 and 4.2.4 as
well as 4.3.0.
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from tdragon at tdragon dot net 2008-05-29 17:31 ---
Created an attachment (id=15702)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15702action=view)
Minimal testcase for vtable issue
I'm not sure whether this is related, but the effect is similar so I'm adding
--- Comment #9 from tdragon at tdragon dot net 2008-05-29 22:13 ---
(In reply to comment #8)
Uhh, if you declare a struct as dllimport, then you are declaring that it's
vtable is defined in a dll. So why is this a bug?
Well, it's a change from mingw32/3.4.5's behavior. At any rate
--- Comment #5 from tdragon at tdragon dot net 2008-04-16 00:50 ---
The issue is fixed for me when applying the mentioned patch to 4.3.0, so as far
as I'm concerned we can close this bug as soon as someone applies the fix to
4.3 SVN.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tdragon at tdragon dot net
GCC build triplet: mingw32
GCC host triplet: mingw32
GCC target triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
--- Comment #1 from tdragon at tdragon dot net 2008-04-12 22:45 ---
Created an attachment (id=15469)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15469action=view)
Minimal testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
--- Comment #30 from tdragon at tdragon dot net 2008-02-22 18:14 ---
Are there sufficient motivation and resources to fix this bug in 4.2? Since 4.3
is soon-to-be, an update on this would be sincerely appreciated -- even if it's
just forgetting about 4.2 and resolving as FIXED
--- Comment #6 from tdragon at tdragon dot net 2007-06-20 14:44 ---
Created an attachment (id=13743)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13743action=view)
Better testcase; compile with -O2, use with alias_main.c
Compiling this file with -O2 and linking with the object
--- Comment #7 from tdragon at tdragon dot net 2007-06-20 14:46 ---
Created an attachment (id=13744)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13744action=view)
Better testcase pt.2; use with alias1.c
Compile this file with any or no additional options as desired; linking
--- Comment #8 from tdragon at tdragon dot net 2007-06-20 14:52 ---
Not seeing any further action or confirmation on this yet, I've gone ahead and
created a simpler testcase. It's plain that, when using -O2, line 14 of
alias1.c is skipped.
--
http://gcc.gnu.org/bugzilla
--- Comment #11 from tdragon at tdragon dot net 2007-06-20 15:35 ---
Not sure if this is relevant or just GCC working differently on my target
system, but I don't encounter the bug using -fstrict-aliasing, or in fact using
individually the entire set of options under -O and -O2 on
http
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tdragon at tdragon dot net
GCC build triplet: i386-pc-mingw32
GCC host triplet: i386-pc-mingw32
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--- Comment #1 from tdragon at tdragon dot net 2007-06-13 21:19 ---
Created an attachment (id=13701)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13701action=view)
Preprocessed example source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
--- Comment #3 from tdragon at tdragon dot net 2007-06-13 22:27 ---
(In reply to comment #2)
Do you mean the last two stores to b:
b-time = time;
b-progress = found ? 4 : 2;
Yes, those two lines are the ones that are wrongly skipped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from tdragon at tdragon dot net 2007-06-13 22:36 ---
(In reply to comment #2)
Though we could have an alias violation if you don't cast back in hashitem to
the correct type of the argument.
hashitem() uses the type as punned to HASHDATA* (where HASHDATA is a struct
--- Comment #5 from tdragon at tdragon dot net 2007-06-13 22:47 ---
Is it possible that an optimization enabled by -O2 *assumes* that hashitem()
will conform with strict aliasing by not dereferencing that argument, and thus
optimizes those lines away? (Not the case.) If this is what
27 matches
Mail list logo
