[Bug debug/33155] New: _stdcall assembler names in win32 vs gdb
My patch:
2007-05-24 Danny Smith [EMAIL PROTECTED]
PR target/27067
* doc/tm.texi (TARGET_MANGLE_DECL_ASSEMBLER_NAME): Document.
* targhooks.h (default_mangle_decl_assembler_name): Declare
default hook.
* targhooks.c (default_mangle_decl_assembler_name): Define
default hook.
* target-def.h (TARGET_MANGLE_DECL_ASSEMBLER_NAME) New. Set to
default hook.
* target.h (struct gcc_target): Add mangle_decl_assembler_name field.
* langhooks.c (lhd_set_decl_assembler_name): Call
targetm.mangle_decl_assembler_name for names with global scope.
breaks gdb usage for setting breakpoints on __stdcall functions in C
(but not C++)
The problem appear to derive from a difference between the DECL_NAME and
DECL_ASSEMBLER_NAME which was introduced by the patch. Windows targets
decorate stdcall assembler identifiers with an @n suffix. Before this
patch, the assembler decoration was only added to RTL names in
encode_section_info; after the patch the decoration is added upfront to
DECL_ASSEMBLER_NAME, because the extern assembler name is really the decorated
name.
Here is an example:
===
/* foo.c */
int __stdcall bar()
{
return 1;
}
int main()
{
return bar();
}
===
Compiling with
gcc -g -xc foo.c
then
C:\develop\bugsgdb a
GNU gdb 6.5.50.20060706-cvs (cygwin-special) Copyright (C) 2006 Free
Software Foundation, Inc. GDB is free software, covered by the GNU
General Public License, and you ar welcome to change it and/or
distribute copies of it under certain condition Type show copying to
see the conditions. There is absolutely no warranty for GDB. Type show
warranty for details. This GDB was configured as i686-pc-cygwin...
(gdb) break bar
Function bar not defined.
However, there are no problems in C++ where there is also (and because
of name mangling, generally) a difference between the the DECL_NAME and
the DECL_ASSEMBLER_NAME.
compiling with
gcc -g -xc++ foo.c
then
C:\develop\bugsgdb a
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i686-pc-cygwin...
(gdb) break bar
Breakpoint 1 at 0x4013a3: file foo.c, line 3.
Reverting this part of the patch
* langhooks.c (lhd_set_decl_assembler_name): Call
targetm.mangle_decl_assembler_name for names with global scope.
avoids the C debugging problem.
gdb knows how to handle C++ mangling diffs between DECL_NAME and
DECL_ASSEMBLER_NAME, so the C++ part of the patch:
* cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name.
doesn't cause any problems.
Danny
--
Summary: _stdcall assembler names in win32 vs gdb
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge 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=33155
[Bug other/18246] struct-layout-1 generator broken on i686-pc-mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-12-09 08:00 --- Fixed for 4.3.0 by http://gcc.gnu.org/viewcvs?view=revrevision=126903 -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18246
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #22 from dannysmith at users dot sourceforge dot net 2007-12-13 08:53 --- (In reply to comment #15) It seems fixincl isn't supported for mingw at all, from what Danny Smith mailed me privately. Sorry for breaking this thread with an inadvertent private mail. For the record here is a post about the mingw vs fixinclude logic: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01044.html Thank you Jakub for the documentation patch. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Version|4.3.0 |2.95 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug libfortran/34712] Formatted write of float broken (mingw32)
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-01-09 06:14 --- This is a dup of PR23138 which is fixed if using recent mingw runtime. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-01-13 06:50 --- (In reply to comment #1) One could make the argument that the dllimport specifier is a storage-class-specifier which, per 11.4/6 is not allowed on the friend declaration. Since a friend function declaration needs to be preceded by a declaration of the function itself, it will always be sufficient if the dllimport specifier is only on the original function declaration. MS semantics for dllimport for ordinary file scope functions, is that if a declaration with dllimport attribute is followed by a decl without, the prior dllimport is overriden. Hence, the warning that Stephen shows for df3.cc in comment #3 may make some sense, but I do not have a MS compiler handy to see what MS says for the friend case. The warning does not make sense, if the dllimport attribute is actually honoured (as it should be) in original testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-01-13 08:32 --- Testing a patch. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-13 08:32:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-01-19 08:33 --- (In reply to comment #4) Testing a patch. Here it is: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00881.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug target/34970] name mangling broken for __attributte__((fastcall))
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-01-26 00:58 --- Confirmed. Fastcall symbols should not be prefixed with USER_LABEL_PREFIX. This bug was introduced with 2007-03-29 Richard Henderson [EMAIL PROTECTED] snip * config/i386/cygming.h: Remove function declarations. (SUBTARGET_ENCODE_SECTION_INFO): Don't undef first. (ASM_OUTPUT_LABELREF): Remove. ... Testing a patch that adds ASM_OUTPUT_LABELREF define back to cygming.h Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|WAITING |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-26 00:58:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34970
[Bug target/34970] [4.3 regression] name mangling broken for __attributte__((fastcall))
--- Comment #10 from dannysmith at users dot sourceforge dot net 2008-01-26 09:41 --- Fixed. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34970
[Bug target/34970] [4.3 regression] name mangling broken for __attributte__((fastcall))
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-01-26 07:17 --- This is a 4.3.0 regression. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Known to fail||4.3.0 Known to work|4.1.3 |4.1.3 4.2.1 Summary|name mangling broken for|[4.3 regression] name |__attributte__((fastcall)) |mangling broken for ||__attributte__((fastcall)) Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34970
[Bug target/35054] New: No documentation of #pragma push_macro(macro_name)
The new feature #pragma push_macro(macro_name) and #pragma pop_macro(macro_name) enabled by 2007-03-30 Richard Henderson [EMAIL PROTECTED] Kai Tietz [EMAIL PROTECTED] * c-pragma.c (struct def_pragma_macro_value): New. (struct def_pragma_macro): New. (pushed_macro_table): New. (dpm_hash, dpm_eq): New. (handle_pragma_push_macro, handle_pragma_pop_macro): New. (init_pragma): Install them. * doc/tm.texi (HANDLE_PRAGMA_PUSH_POP_MACRO): New. is not documented as a user extension in extend.texi -- Summary: No documentation of #pragma push_macro(macro_name) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35054
[Bug preprocessor/35061] New: #pragma pop_macro causes ICE if no macro value on stack
A #pragma pop_macro without a preceding #pragma push_macro triggers an ICE
on mingw32
// pop_macro.c
#define X 1
int main()
{
// # pragma push_macro(X)
# undef X
# define X 2
# pragma pop_macro(X)
return 0;
}
gcc pop_macro.c
pop_macro.c: In function 'main':
pop_macro.c:9: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: #pragma pop_macro causes ICE if no macro value on stack
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35061
[Bug target/35054] No documentation of #pragma push_macro(macro_name)
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-05 09:37 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00118.html danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-05 09:37:33 date|| Summary|No documentation of #pragma|No documentation of #pragma |push_macro(macro_name)|push_macro(macro_name) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35054
[Bug preprocessor/35061] #pragma pop_macro causes ICE if no macro value on stack
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-06 17:29 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00120.html -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|NEW |ASSIGNED Last reconfirmed|2008-02-06 10:56:34 |2008-02-06 17:29:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35061
[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-02-14 01:43 --- Actually, I see this as unfortunate choice of name for the undocumented __alloca label rather than as a serious bug. __alloca is an internal symbol that should have been named _alloca_probe for consistency with MSVCT. Certainly it is not a regression. It has been that way since 1996. The mingw header malloc.h does this to get a MSVCRT-consistent alloca: #ifdef __GNUC__ #define _alloca(x) __builtin_alloca((x)) #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-02-14 08:14 --- And just think of the havoc that will be caused with old mingw32 and cygwin libs that depend on the _chkstk meaning of __alloca if you change __alloca semantics. eg there are 69 undefined references to __alloca in mingw32-gcc-4.2.1 built libgmp.a In my opinion it is a bug that 64 bit mingw defines __alloca differently to 32 bit mingw. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-02-14
17:46 ---
(In reply to comment #6)
I agree, that the havoc for 32-bit backward compatibility is to avoid.
But the havoc for windows sources using -fno-builtin and using _alloca () for
stack allocation produces in future even more troubles IMHO.
Why should windows sources need to use __alloca.
If someone really wants an MSCV compatible (one underscore) _alloca they just
add this to their srcs
void *_alloca (size_t size) {return __builtin_alloca (size));
MSDN documentation says that This function is deprecated because a more secure
version is available; see _malloca.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
[Bug target/35124] Method _alloca is defined different by MSVCRT as by gcc.
--- Comment #8 from dannysmith at users dot sourceforge dot net 2008-02-14
20:10 ---
(In reply to comment #7)
If someone really wants an MSCV compatible (one underscore) _alloca they just
add this to their srcs
void *_alloca (size_t size) {return __builtin_alloca (size));
Ugh. Sorry, I wasn't thinking clearly. Currently, that will lead to circular
reference. I'll change gen_allocate_stack_worker to use __chkstk for 32-bits
when 4.4. opens.
Just #define _alloca __builtin_alloca, That isn't affected by -fno-builtin
anyway
Danny
MSDN documentation says that This function is deprecated because a more
secure
version is available; see _malloca.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35124
[Bug preprocessor/35061] #pragma pop_macro causes ICE if no macro value on stack
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-02-14 21:44 --- Fixed -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35061
[Bug fortran/33281] gfortran crt2.o not found under Vista
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-04
06:17 ---
The solution is to build gcc/gfortran wiith -D__USE_MINGW_ACCESS in CFLAGS;
From mingw/include/io.h
/* Some defines for _access nAccessMode (MS doesn't define them, but
* it doesn't seem to hurt to add them). */
#define F_OK0 /* Check for file existence */
/* Well maybe it does hurt. On newer versions of MSVCRT, an access mode
of 1 causes invalid parameter error. */
#define X_OK1 /* MS access() doesn't check for execute permission. */
#define W_OK2 /* Check for write permission */
#define R_OK4 /* Check for read permission */
and later:
#ifdef __USE_MINGW_ACCESS
/* Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code. This will restore the
old behaviour */
static inline int __mingw_access (const char* __fname, int __mode)
{ return _access (__fname, __mode ~X_OK); }
#define access(__f,__m) __mingw_access (__f, __m)
#endif
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-09-04 06:17:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug libstdc++/33203] [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-05 19:00 --- A patch is at: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00310.html Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-05 19:00:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203
[Bug libstdc++/33328] New: sys_nerr declaration assumed to be in errno.h
libstdc++-v3/acinclude.m4 tests if sys_nerr is in errno.h. On mingw32, it is declared in stdlib.h, so autoconf test fails. Judging from comment in libiberty/strerror.c, sys_nerr is declared in stdio.h on BSD. -- Summary: sys_nerr declaration assumed to be in errno.h Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33328
[Bug libstdc++/33203] [4.3 regression] libstdc++-v3 build broken on i386-pc-mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-07 04:21 --- Fixed. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33203
[Bug c++/14688] Mis-matched calling convention on virtual functions accepted without error
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-19 00:58 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01498.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14688
[Bug c++/15774] Conflicting function decls not diagnosed
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-09-19 21:52 --- With 4.1, 4.2 and trunk, there is still no diagnosis of change in calling convention in decl, but the bug in generated code is exposed only with -fno-unit-at-time. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Known to fail|2.95.3 3.3.3 3.4.0 4.0.0|2.95.3 3.3.3 3.4.0 4.0.0 ||4.1.0 4.2.1 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15774
[Bug target/12413] 'symbol already defined' when building ICU 2.6 with Cygwin
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-20 21:24 --- This testcase compiles with problem on trunk and 4.2.2. I haven't tested 4.1.x Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413
[Bug target/24472] Invalid global deinitialization order
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-09-20 21:36 --- This is fixed on trunk by TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT patch http://gcc.gnu.org/viewcvs?root=gccview=revrev=118371 Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24472
[Bug c++/20221] Declspec sequences on pointer declarations: C++ vs C
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-09-20 21:53 --- With 4.2 and trunk, I get the same (expected) result on C and C++. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20221
[Bug testsuite/20360] 20021014-1.c fails on account of unsupported build option
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-09-20
22:01 ---
The addition of
/* { dg-require-profiling -p } */
has resolved this on at least 4.2.2 and trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||FIXED
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20360
[Bug target/10135] Uncaught exceptions with --disable-sjlj-exceptions configured GCC
--- Comment #11 from dannysmith at users dot sourceforge dot net 2007-09-20 23:43 --- You can --disable-sjlj-exceptions on cygwin and mingw now. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10135
[Bug target/17300] [mingw/cygwin]: dllimport of C++ classes with vtables causes bogus symbol ref
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-09-21 03:04 --- The example produces a correct label for the vtable (_ZTV1S) with 4.2.2 and trunk, so closing as fixed. However we still emit the definition of the vtable even though we import it from the dll as __imp___ZTV1S when constructing the object s. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17300
[Bug c++/14688] Mis-matched calling convention on virtual functions accepted without error
--- Comment #8 from dannysmith at users dot sourceforge dot net 2007-09-25 00:31 --- Fixed on trunk -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14688
[Bug libstdc++/33578] New: libstdc++ parallel mode broken on mingw32
/develop/svn/trunk/build/mingw32/libstdc++-v3/include/parallel/compatibility.h: In function 'void __gnu_parallel::yield()': /develop/svn/trunk/build/mingw32/libstdc++-v3/include/parallel/compatibility.h:331: error: 'Sleep' was not declared in this scope make[4]: *** [parallel_list.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [all] Error 2 The 'obvious' fix is to just include windows.h for __MINGW32__ as well as _MSC_VER to get the prototype for Sleep. However, I expect that would cause many complaints because it would pollute the global namespace with all the Win32api names. These do cause problems in practice , especially when porting non-Win32 apps to mingw32. The _GTHREAD_HIDE_W32API business in gthr-win32.h was implemented precisely to avoid having to expose these names in libstdc++. From a mingw point of view it would be better if __gnu_parallel::yield could be hidden away either in a gthread_sched_yield function in libgcc or in a libstdc++ object file. Secondly, I don't think Sleep is actually the correct function to call on NT4 and later The SwitchToThread() function which Causes the calling thread to yield execution to another thread that is ready to run on the current processor. The operating system selects the next thread to be executed. may be better. Danny -- Summary: libstdc++ parallel mode broken on mingw32 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33578
[Bug libstdc++/33603] configuration failure during native build
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-10-04 08:26 --- (In reply to comment #2) While looking for collect2, I realized the path to ld (and as) had been misdetected. Explicit specification of the path, --with-ld=/mingw/bin/ld.exe, let me have a successful configuration. The buikd is now past the confiuguration step. I hope there won't be anymore failure. Many thanks! Is this type of failure documented somewhere? Explicit specification of the path to ld and as has bot been necessary on my native builds on WinXP host, using cygwin bash. But possibly I am just avoidng the problem by using 'identity' mounts -- mounts where the posix path equate to the DOS path on the current drive. eg, c:\mingw is mounted as /mingw. etc so both the posix tools (like exec in the ld scrtpt) and the native executables refer to the same path. Danny -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
[Bug libstdc++/33603] configuration failure during native build
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-10-05 07:03 --- (In reply to comment #4) However, for some reasons, the path to ld is detected as: c:/Docume~1/gdr/Desktop/sandbox/eval-build/i686-pc-mingw32/libstdc++-v3/c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/ld.exe which is not right. I suspect the real path is c:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/bin/ld.exe but somehow it is appended to the build directory path. Furthermore, it looks a very complicated path name. How do you configure? Combined binutils/gcc in-tree build with this configuration ../src/configure --host=mingw32 --build=mingw32 --target=mingw32 --with-arch=i486 --with-cpu=generic --disable-werror --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,objc,obj-c++,fortran --disable-win32-registry --enable-libstdcxx-debug --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-version-specific-runtime-lib --enable-libgomp --disable-sjlj-exceptions --enable-shared --disable-symvers works for me. Configure correctly sets ORIGINAL_LD_FOR_TARGET=../ld/ld-new.exe If I move binutils out of tree then I get ORIGINAL_LD_FOR_TARGET=/mingw/mingw32/bin/ld which also works correctly. Are you using MSYS or cygwin bash and tools? Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33603
[Bug libstdc++/33682] New: libstdc++ broken for !__GTHREAD_HAS_COND hosts
../../../../gcc/libstdc++-v3/libsupc++/guard.cc:68: error: expected initializer before '*' token ../../../../gcc/libstdc++-v3/libsupc++/guard.cc:71: error: '__cond' is not a member of '__gnu_cxx' ../../../../gcc/libstdc++-v3/libsupc++/guard.cc:72: error: '__cond' is not a member of '__gnu_cxx' ../../../../gcc/libstdc++-v3/libsupc++/guard.cc:73: error: 'fake_cond_t' does not name a type ../../../../gcc/libstdc++-v3/libsupc++/guard.cc: In function 'voidunnamed::init_static_cond()': ../../../../gcc/libstdc++-v3/libsupc++/guard.cc:76: error: 'static_cond' was not declared in this scope -- Summary: libstdc++ broken for !__GTHREAD_HAS_COND hosts Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33682
[Bug libstdc++/33682] libstdc++ broken for !__GTHREAD_HAS_COND hosts
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-06 21:53 --- The 'obvious' patch is here: http://gcc.gnu.org/ml/libstdc++/2007-10/msg00043.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33682
[Bug libstdc++/33578] __gnu_parallel::yield broken on mingw32
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-10-09 23:52 --- Created an attachment (id=14334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14334action=view) mingw32 compatibility patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33578
[Bug libstdc++/33578] __gnu_parallel::yield broken on mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-10-09 23:54 --- (In reply to comment #2) Created an attachment (id=14332) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14332action=view) [edit] Consistent use of _WIN32 define Thats not quite right. ___MINGW32__ defines _WIN32 but doesn't have an intrin.h. I believe that is for MSVC compiler specific intrinsics. _MSC_VER is a MSVC compiler builtin define. Also, Cygwin __may__ define _W32 (with -mwin32 switch) but still should use its own implementation of sched.h and sched_yield since it uses pthreads I'll attach what I'm using currently. Putting more #ifdef's into this file certainly doesn't make it any prettier. If wanted, I could prepare a patch that gets rid of *all* the non-GNU (Windows) stuff and just put a __MINGW32__ specific definition of a __gnu_parallel::sched_yield() into os_defines.h. FWIW, boost uses Sleep(1) -- not Sleep(0) -- for sched_yield() on windows, while cygwin use SwitchToThread() Dann\y -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33578
[Bug libstdc++/33682] libstdc++ broken for !__GTHREAD_HAS_COND hosts
--- Comment #6 from dannysmith at users dot sourceforge dot net 2007-10-10 19:26 --- Fixed. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33682
[Bug target/33774] New: Cygwin/mingw do not support 16 byte alignment of struct/union fields
The following testcase fails on mingw32
===
typedef int __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef union
{
float f[4];
__m128 m;
} foo;
int test1[__alignof(__m128) = 16 ? 1 : -1 ]; // OK
int test2[__alignof(foo) = 16 ? 1 : -1 ]; // Fails: alignof foo = 8
with:
foo.c:11: error: size of array 'test2' is negative.
The problem is config/i386/cygming.h
#define BIGGEST_FIELD_ALIGNMENT 64
which is a leftover from a time when this define was necessary and
sufficient to enable 8 byte alignment for doubles--consistent with the
target default MASK_ALIGN_DOUBLE--and when GNU ld could only handle 8
byte alignment.
Currently testing a patch.
--
Summary: Cygwin/mingw do not support 16 byte alignment of
struct/union fields
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: dannysmith at users dot sourceforge dot net
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33774
[Bug c/33777] Crash during a build of zsh
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-10-15 09:00 --- I believe this is a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826 The bug was closed as fixed but reappeared on 4.2.x when Richard Henderson's TLS emulation patch was reverted on the branch. See comment #16 in PR 29826 for a patch. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33777
[Bug target/33774] Cygwin/mingw do not support 16 byte alignment of struct/union fields
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-10-18 21:04 --- The native compiler MSVC++ does not limit field alignment to 64 bits, but as documented here Windows Data Alignment on IPF, x86, and x64 http://msdn2.microsoft.com/en-us/library/Aa290049(VS.71).aspx supports at least up to 256-bit field alignment (see Listing 5 in above article). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33774
[Bug c++/33900] (exception handling) bad/inconsistent code generation
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-25 20:41 --- My reading of 18.7.5 of C++98 standard says that throwing an exeception from a signal handler is implementation-defined, since such a signal handler is not a POF. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33900
[Bug target/33918] GCC failed to produce assembler output with -masm=intel option
--- Comment #1 from dannysmith at users dot sourceforge dot net 2007-10-27 00:52 --- Same error message as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18353 This works with revision 129548 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33918
[Bug testsuite/33946] New: Testcase multi-ix.c generates call to (poisoned) bzero
testsuite gcc.c-torture/execute/multi-ix.c calls __builtin_bzero; At -O0, this gets expanded to a libcall to non-ISO function bzero mingw32 does not have a library function bzero.. Hence: spawn /develop/svn/trunk/build/gcc/xgcc -B/develop/svn/trunk/build/gcc/ /develop/svn/trunk/src/gcc/testsuite/gcc.c-torture/execute/multi-ix.c -w -O0 -fno-show-column -lm -o /develop/svn/trunk/build/gcc/testsuite/gcc/multi-ix.x0 c:\tmp/ccsxRYXw.o:multi-ix.c:(.text+0x9a3): undefined reference to `_bzero' Why not use ___builtin_memset in the testcase instead of poisoned name ? -- Summary: Testcase multi-ix.c generates call to (poisoned) bzero Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33946
[Bug target/33963] New: Dllimport attribute wrongly accepted on typedefs
Testcase gcc.dg/attr-invalid.c started failing on mingw32 with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=125975
In particular, this delta
* tree.c (handle_dll_attribute): Set DECL_VISIBILITY on the
imported or exported declaration, including type declarations.
made these TYPE_DECL's valid:
# 88 attr-invalid.c
typedef int dllimport_type __attribute__((dllimport));
typedef int (*dllimport_fntype)(void) __attribute__((dllimport));
Prior to that revision the attribute was valid only on FUNCTION_DECLS's
and VAR_DECL's
However, although there is no warning, the attribute is ignored
typedef int dllimport_type __attribute__((dllimport));
extern dllimport_type foo;
int bar () { return foo; }
gives
_bar:
pushl %ebp
movl%esp, %ebp
movl_foo, %eax
popl%ebp
ret
--
Summary: Dllimport attribute wrongly accepted on typedefs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33963
[Bug c++/34032] -std=c++0x causes undeclared symbols errors on cygwin
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-11-08 19:18 --- The newlib stdio.h puts [v]snprintf declarations within a #ifndef __STRICT_ANSI__ block. Likewise for cygwin's ctype.h and isblank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34032
[Bug target/33774] Cygwin/mingw do not support 16 byte alignment of struct/union fields
--- Comment #4 from dannysmith at users dot sourceforge dot net 2007-11-08 20:21 --- Fixed on trunk. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33774
[Bug fortran/34112] Add $!DEC ATTRIBUTE support for 32bit Windows' STDCALL
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-11-16 23:09 --- The problem with decorate is that its meaning depends on the platform. It may decorate the name of alias with a _ prefix and @n postfix or only with a _ prefix. Maybe one should start with STDCALL and ALIAS. Would the target hook TARGET_MANGLE_DECL_ASSEMBLER_NAME (see tm.texi, also config/i386/winnt.c for implementation) help here? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34112
[Bug bootstrap/39660] Mingw Bootstrap stops with ..host-mingw32.c:140: error: ISO C90 forbids mixed..
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-07 03:39:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39660
[Bug bootstrap/39660] Mingw Bootstrap stops with ..host-mingw32.c:140: error: ISO C90 forbids mixed..
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-08 08:12 --- Fixed. -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39660
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #53 from dannysmith at users dot sourceforge dot net 2009-04-16 02:59 --- This thread is alos relevant. http://gcc.gnu.org/ml/gcc/2009-04/msg00462.html Adding Dave Korn to cc: -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/39947] Shared libgcc getting clobbered for multilib builds
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29 07:29 --- The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll, libssp-x.dll, etc) that are built as part of gcc Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39947
[Bug target/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #9 from dannysmith at users dot sourceforge dot net 2009-04-30 20:57 --- (In reply to comment #6) (In reply to comment #4) Your libpthreads is doing something wrong. Re. comment 5 The command was actually gcc -fopemnp test.c -lgomp -o test.exe That command works for me with gcc 4.3.4, 4.4.0 and trunk In 4.4.0 and trunk, test.exe links against LIBGOMP-1.DLL which in turn resolves the pthread imports from PTHREADGCE2.DLL, which is distributed by the pthreads-win32 project http://sources.redhat.com/pthreads-win32/ My version of 4.3.4 has local mods. I'm not sure if the shared libgomp build was standard then. How did you build gcc-4.3.0? You need to add --enable-libgomp to configure and ensure that libpthread.a (note spelling) can be found. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug target/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #10 from dannysmith at users dot sourceforge dot net
2009-04-30 21:07 ---
(In reply to comment #9)
(In reply to comment #6)
(In reply to comment #4)
Your libpthreads is doing something wrong.
Re. comment 5
The command was actually
gcc -fopemnp test.c -lgomp -o test.exe
That command works for me with gcc 4.3.4, 4.4.0 and trunk
In 4.4.0 and trunk, test.exe links against LIBGOMP-1.DLL which in turn
resolves
the pthread imports from PTHREADGCE2.DLL, which is distributed by the
pthreads-win32 project
http://sources.redhat.com/pthreads-win32/
My version of 4.3.4 has local mods. I'm not sure if the shared libgomp build
was standard then.
No it wasn't. And so the problem is that libgomp.spec says:
# This spec file is read by gcc when linking. It is used to specify the
# standard libraries we need in order to link with -fopenmp.
*link_gomp: -lgomp %{static: -lpthread }
You have not specified '-static', so you must provide the '-lpthread' (again
note spelling) yourself.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|target |libgomp Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug libgomp/39939] MinGW 4.3.0 fails to link sample programme.
--- Comment #12 from dannysmith at users dot sourceforge dot net 2009-05-01 19:48 --- (In reply to comment #11) (In reply to comment #9, comment #10) I did not build MinGW 4.3.0. I got it from the official MinGW site (gcc-4.3.0-20080502-mingw32-alpha). I have also found that on www.equation.com there are even newer versions (binaries), like 4.3.3 with OpenMP 2.5, 4.4.0 with OpenMP 3.0 and MinGW 4.5 compilation snapshot. They seem to work fine with OpenMP. Its a shame that www.equation.com doesn't tell us how to obtain their source code for the gcc, gdb ands make binaries. They aren't present on the official MinGW site. Why? No one has had put them there. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39939
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-05-10
05:01 ---
(In reply to comment #3)
Created an attachment (id=17841)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841action=view) [edit]
inherit dllexport from class to typeinfo
Now testing a solution based on the approach of adding the dllexport attribute
to the class' typeinfo object when the class is passed to
i386_pe_adjust_class_at_definition.
Hello Dave,
Rather than use DLL linkage (and so force client to resort to auto-import
magic)
why not just always emit the RTTI with one-only comdat linkage.
* decl2.c (import_export_decl): Always emit RTTI with comdat linkage
rather than import if MULTIPLE_SYMBOL_SPACES.
Index: decl2.c
===
--- decl2.c (revision 147015)
+++ decl2.c (working copy)
@@ -2351,15 +2351,21 @@
{
class_type = type;
import_export_class (type);
- if (CLASSTYPE_INTERFACE_KNOWN (type)
- TYPE_POLYMORPHIC_P (type)
- CLASSTYPE_INTERFACE_ONLY (type)
- /* If -fno-rtti was specified, then we cannot be sure
-that RTTI information will be emitted with the
-virtual table of the class, so we must emit it
-wherever it is used. */
- flag_rtti)
- import_p = true;
+ /* Do not import typeinfo if the class might be in a DLL.
+Dllimports do not have a constant address at compile time,
+causing problems for static initialization of tables with RTTI
+fields. Set to comdat instead. */
+ if (MULTIPLE_SYMBOL_SPACES)
+ comdat_p = true;
+ else if (CLASSTYPE_INTERFACE_KNOWN (type)
+ TYPE_POLYMORPHIC_P (type)
+ CLASSTYPE_INTERFACE_ONLY (type)
+ /* If -fno-rtti was specified, then we cannot be sure
+ that RTTI information will be emitted with the
+ virtual table of the class, so we must emit it
+ wherever it is used. */
+ flag_rtti)
+import_p = true;
else
{
if (CLASSTYPE_INTERFACE_KNOWN (type)
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org |sourceforge dot net
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-05-10 05:01:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-13 08:12 --- (In reply to comment #5) Also, I don't think this is necessarily an either-or situation; we could add my patch and have the typeinfo exported from the DLL, and also add yours so that clients could link a comdat copy (which would override the import stub) until we have a better solution for importing from the DLL. Yes. I was just thinking out loud. I have no objection to your patch. Perhaps MULTIPLE_SYMBOL_SPACES should be defined in terms of an -mmultiple-symbol-spaces target option , since if we depend on auto-import than we should treat dll imports thae same as static lib imports. Also, how come emitting the typeinfo .linkonce as we currently do isn't the same as COMDAT for these purposes? I'm not sure I understand your question. In earlier versions of G++, both vtables and typeinfo were always emitted with linkonce semantics, because of the MULTIPLE_SYMBOL_SPACES define. Regards Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-28 08:26 --- (In reply to comment #4) Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it does not know those functions should be enabled. mingw does not yet provide ANSI (c99) compliant swprintf or vswprintf implementations. The functions it does provide, _swprintf and _vswprintf, are pre-c99 MSVCRT implementations. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug target/42213] GCC chkstk clash with Microsoft version
--- Comment #3 from dannysmith at users dot sourceforge dot net 2009-11-29 17:36 --- see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356#c9 and discussion of http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html I think that patch should go into 4.5 Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42213
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-24 03:12 --- This bug is linker related. It is fixed on 32-bit windows by this patch http://sourceware.org/ml/binutils-cvs/2007-10/msg2.html Have you tried with recent binutils and explict -Wl,--enable-auto-import switch? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug c++/34749] Incorrect warning when applying dllimport to friend function
--- Comment #7 from dannysmith at users dot sourceforge dot net 2008-09-26 03:15 --- *** Bug 37652 has been marked as a duplicate of this bug. *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||v dot haisman at sh dot cvut ||dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34749
[Bug target/37652] Bogus redeclaration warning for `friend __declspec(dllimport) int foo ()'
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-26 03:15 --- This is duplicate of 34749 *** This bug has been marked as a duplicate of 34749 *** -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37652
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #19 from dannysmith at users dot sourceforge dot net 2008-09-29 18:43 --- Created an attachment (id=16427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16427action=view) Nick's aligned common testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #26 from dannysmith at users dot sourceforge dot net 2008-10-01 01:33 --- (In reply to comment #14) Hi Guys, I am not able to reproduce the build problems that were reported with the first version of my patch, but then again I do not have a native cygwin build system or a system in which I can bootstrap mingw32. I think that Brian may well be right however in that the patch is behaving badly when it manually switches into the .bss section. I have uploaded a revised version of the patch which uses the correct gcc function to perform the section switch, so please can anyone who is interested give this new patch a run. This latter patch, applied to R139853 [*] (just before the big IRA merge) does not cause the build problems of the prior patch but does not solve the problem either. With this patch, using your _align.c test case which I uploaded in previous comment: gcc -DHAVE_ALIGNED_COMMON _align.c a.exe fails. The assembler code, specifically the .balign 32 directive applied to the _common object looks like it should do the right thing, but doesn't (: .file _align.c .bss .balign 1 .comm _a, 1 .balign 32 .comm _common, 64 .globl _b .section.bss,w _b: .space 1 .globl _bss .align 32 _bss: .space 64 .globl _c .data _c: .byte 1 .globl _data .align 32 _data: .long 1 .space 4 .long 2 .space 4 .long 3 .space 12 .long 4 .space 28 .text .globl _test .def_test; .scl2; .type 32; .endef _test: pushl %ebp movl%esp, %ebp subl$8, %esp movl8(%ebp), %eax addl$8, %eax andl$7, %eax testl %eax, %eax jne L2 movl8(%ebp), %eax addl$16, %eax andl$15, %eax testl %eax, %eax jne L2 movl8(%ebp), %eax addl$32, %eax andl$31, %eax testl %eax, %eax je L4 L2: call_abort L4: leave ret .def___main;.scl2; .type 32; .endef .globl _main .def_main; .scl2; .type 32; .endef _main: pushl %ebp movl%esp, %ebp andl$-16, %esp subl$16, %esp call___main movl$_common, (%esp) call_test movl$_bss, (%esp) call_test movl$_data, (%esp) call_test movl$0, (%esp) call_exit .def_abort; .scl2; .type 32; .endef .def_exit; .scl2; .type 32; .endef [*] Since the IRA merge, mingw32 has been broken, failing to compile libstdc++ and raising many (500 in gcc.dg) new testcase errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #27 from dannysmith at users dot sourceforge dot net
2008-10-01 10:22 ---
(In reply to comment #13)
Created an attachment (id=16425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16425action=view) [edit]
Revised patch with correct section switching
That patch causes other problems
This test case:
/* t1.c */
int i[0];
int k;
void testi (void)
{
i[0] = 0;
}
void testk (void)
{
k = 0;
}
int main (void)
{
return 0;
}
now fails with
t1.c:(.text+0x5): undefined reference to `_i'
The assembler code is
.file t1.c
.text
.p2align 4,,15
.globl _testi
.def_testi; .scl2; .type 32; .endef
_testi:
pushl %ebp
movl%esp, %ebp
movl$0, _i
popl%ebp
ret
.p2align 4,,15
.globl _testk
.def_testk; .scl2; .type 32; .endef
_testk:
pushl %ebp
movl%esp, %ebp
movl$0, _k
popl%ebp
ret
.def___main;.scl2; .type 32; .endef
.p2align 4,,15
.globl _main
.def_main; .scl2; .type 32; .endef
_main:
pushl %ebp
movl%esp, %ebp
andl$-16, %esp
call___main
xorl%eax, %eax
movl%ebp, %esp
popl%ebp
ret
.bss
.balign 4
.comm _i, 0 size of i[0]
.balign 4
.comm _k, 4
I suspect we need to add this bit, or similar, back in
- rounded = size ? size : 1;
- rounded += (BIGGEST_ALIGNMENT / BITS_PER_UNIT) - 1;
- rounded = (rounded / (BIGGEST_ALIGNMENT / BITS_PER_UNIT)
-* (BIGGEST_ALIGNMENT / BITS_PER_UNIT));
and output rounded rather than size.
Testing now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-10-02 00:20 --- In reply to comment #4) xgcc: error trying to exec '/cygdrive/c/jimdata/home/cvsroot/gcc-obj/./prev-gcc/cc1.exe': execv: Permission denied This may be related to: http://gcc.gnu.org/ml/gcc-bugs/2007-05/msg00228.html Windows filesystems have woefully poor timestamp resolution, so it is easy to get in race situation with modern CPUS. I find that it helps to disable explorer.exe in the Windows TaskManager while doing a bootstrap. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702
[Bug target/37528] [4.4 Regression] boostrap failure due to configure problems
--- Comment #10 from dannysmith at users dot sourceforge dot net 2008-10-02 08:47 --- Fixed on mingw32 at revision 140803. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37528
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #41 from dannysmith at users dot sourceforge dot net 2008-10-06 20:18 --- (In reply to comment #35) As I suspected. The PE/COFF file format does not provide for specifying the alignment of commons. Hmm, I wonder if gcc should complain if it finds aligned commons with COFF backends or if we should try to generate a GNU extension to the COFF format. Aligned commons are not part of the PE COFF spec and AFAICT neither MASM nor NASM provide a way to specify aligned commons. I am afraid that a GNU extension will cause object incompatibility, so it would it need to be a non-default option. We already have -fno-common __attribute__((no_common)) #pragma gcc optimize (no_common) G++ already puts commons in .bss Perhaps a new option -fno_large_common that applies -fcommon only to objects with align = 4 bytes? A warning would be useful in any case. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-03 06:09:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-03 07:45 --- Created an attachment (id=16614) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16614action=view) revised patch to quard with ENABLE_SHARED_LIBGCC Hi Mikael, I have modified your patch slightly and added a ChangeLog entry. It works for me with host=build=target=mingw32. Does attached it work for you. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug target/37989] PR37528 fix broke --disable-shared on mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-04 02:21 --- Fixed by Mikael's patch -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
[Bug middle-end/38054] Assertion failed in change_decl_assembler_name()
-- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-09 00:41:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-11-09 08:20 --- This a target bug (stdcall symbol name decorati0on on windows targets) -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-09 08:24 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-11 06:27 --- (In reply to comment #3) Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00321.html That patch also fixes the FAIL of testsuite\g++.old-deja\g++.dg\otherg++ pr35504.C . Currently it fails on mingw32 and cygwin with: Warning: resolving non-virtual thunk to c3::method5()@4 by linking to non-virtual thunk to c3::method5() Use --enable-stdcall-fixup to disable these warnings Use --disable-stdcall-fixup to disable these fixups c:\tmp/ccisCRqc.o:pr35504.C:(.rdata$_ZTV2c3[vtable for c3]+0x44): undefined reference to [EMAIL PROTECTED]@4' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38130] New: [4.4.0 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
Execution testcases c-torture/execute/920929-1.c and c-torture/execute/built-in-setjmp.c began failing on mingw32 in late August, coincident with merge of IRA into trunk. In both cases, the execution tests pass if -fno-ira is added to command line. The problem appears to be in the call of the target stack-probing code (__chkstk) in cygwin.asm from allocate_stack_worker instruction. __chkstk has unusual calling convention, with the input argument as well as the output passed in eax. From i386.md: (define_insn allocate_stack_worker_32 [(set (match_operand:SI 0 register_operand +a) (unspec_volatile:SI [(match_dup 0)] UNSPECV_STACK_PROBE)) (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 0))) (clobber (reg:CC FLAGS_REG))] !TARGET_64BIT TARGET_STACK_PROBE call\t___chkstk [(set_attr type multi) (set_attr length 5)]) The relevant part of the output of gcc -S -O -funroll-all-loops 920929-1.c -o 920929-1-IRA.s: f: pushl %ebp movl%esp, %ebp pushl %ebx subl$4, %esp movl8(%ebp), %edx call___chkstk leal15(%esp), %ecx andl$-16, %ecx testl %edx, %edx ... __chkstk allocates only 1 byte and the code segfault on the first attempt to assign a double to the allocated array. The output, with -fno-ira gcc -S -O -funroll-all-loops -fno-ira 920929-1.c -o 920929-1-NOIRA.s: _f: pushl %ebp movl%esp, %ebp pushl %ebx subl$4, %esp movl8(%ebp), %ebx leal30(,%ebx,8), %eax andl$-16, %eax call___chkstk leal15(%esp), %eax movl%eax, %edx andl$-16, %edx testl %ebx, %ebx __chkstk allocates 816 bytes A comparison of built-in-setjmp.c with amd without -fno-ira switch also shows incorrect input to __chkstk Probably related to these failure is miscompilation of the C++ compiler code cp/pt.c, which segfaults following call to alloca in process_partial_specialization when building libstdc++. If cp/pt.c is compiled with -fno-ira, libstdc++ builds successfully. Danny -- Summary: [4.4.0 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug target/38130] [4.4 regression]__builtin_alloca (vs IRA?) testsuite failures on mingw32
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-18 05:55 --- (In reply to comment #4) Created an attachment (id=16713) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713action=view) [edit] gcc44-pr38130.patch I've talked about this with Honza on IRC: honza I would just use 0 constraint. At least in old times with regmove, regmove was able to discover that it should use same pseudo for input and output. If you use pair of =a and a only reload sees this fact honza so patch is OK with that change. This is an updated patch which uses 0 instead of a constraint for operand 1. So, can anyone please test it? Thanks. This patch bootstraps on mingw32 (c,c++,gfortran) successfully, libstcd++ now compiles and the two testcases reported as failing now pass. A full regtest is in progress and so far looks good. Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38130
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-11-18 06:26 --- Hello Murali, Does the patch for PR 38130 fix the build of libstdc++ on cygwin? http://gcc.gnu.org/bugzilla/attachment.cgi?id=16713action=view Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-11-21 05:51 --- (In reply to comment #4) Creating library file: .libs/libssp.dll.a .libs/ssp.o: In function `fail': /home/vmk/gccdev/gcctr11/gcc/libssp/ssp.c:109: undefined reference to `___chkstk' .libs/gets-chk.o: In function `__gets_chk': /home/vmk/gccdev/gcctr11/gcc/libssp/gets-chk.c:66: undefined reference to `___chkstk' This is a different bug. Cygwin uses the rules in gcc.c:init_gcc_specs to Add appropriate libgcc specs to OBSTACK, taking into account various permutations of -shared-libgcc, -shared, and such. These do not quite work for Windows targets because dll's do not allow any reference to be undefined whey they are built. Thus, the static libgcc.a must generally be included to resolve, eg __chkstk.mingw works around this by defining it's own REAL_LIBGCC_SPEC in mingw32.h that does this. Perhaps cygwin should do the same. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dave dot korn at artimi dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #33 from dannysmith at users dot sourceforge dot net 2008-11-24 06:41 --- (In reply to comment #32) I've been told that this is related to the test case I just attached Your testcase is more closely related to PR 38054. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #11 from dannysmith at users dot sourceforge dot net 2008-12-02 08:05 --- I have committed a patch to 4.4.0 to fix bug in compilation of desktop.cpp -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38054] Assertion failed in change_decl_assembler_name()
--- Comment #13 from dannysmith at users dot sourceforge dot net 2008-12-04 07:16 --- Fixed in 4.3.3 -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.4 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38054
[Bug target/38294] Enable multilib support for mingw
--- Comment #9 from dannysmith at users dot sourceforge dot net 2008-12-14 05:54 --- (In reply to comment #5) Reasoned by the fact, that this patch will solve our build failures for w64, it is really more to be treated as regression. NightStrike, when all tests you are doing at the moment are passing, I'll sent it tomorrow to gcc-patches. Danny is this ok for you? I would prefer that this be left until 4.5. I don't understand how failing to add a new feature is now a regression. (In reply to comment #6) Created an attachment (id=16906) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16906action=view) [edit] Third attempt There were a few lines in t-mingw32 that were commented out and shouldn't have been there. Fixed in this patch. Please also remove this unnecessary change in mingw32.h +#if TARGET_64BIT_DEFAULT #define STANDARD_INCLUDE_DIR /mingw/include +#else +#define STANDARD_INCLUDE_DIR /mingw/include #endif Nightstrike, have you completed FSF copyright assignment formality Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38294
[Bug bootstrap/38580] Bootstrap broken on mingw32
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-12-19 23:01 --- Patch for this was submitted 4 months ago: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01143.html Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-19 23:01:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38580
[Bug c++/36654] [4.2/4.3 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-01-02
04:19 ---
Hello John,
This patch:
Index: gcc/config/i386/winnt-cxx.c
===
--- gcc/config/i386/winnt-cxx.c (revision 142383)
+++ gcc/config/i386/winnt-cxx.c (working copy)
@@ -65,7 +65,7 @@
ignore the class attribute. */
else if (TREE_CODE (decl) == VAR_DECL
TREE_STATIC (decl) TREE_PUBLIC (decl)
- !DECL_EXTERNAL (decl))
+ DECL_NOT_REALLY_EXTERN (decl))
{
if (!DECL_VIRTUAL_P (decl))
error (definition of static data member %q+D of
fixes your testcase and causes no regressions in g++ testsuite. I have only
tested on narrow range of dll builds, to check that the patch does not break
anything. I think it may cause spurious errors with import of static data
members, but that can be fixed. Could you please test with your projects.
Thanks
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
[Bug bootstrap/35273] New: [4.3.0 regression] Bootstrap of mingw32 using non-MSYS sehll broken
gcc/ChangeLog: 2008-02-17 Ralf Wildenhues [EMAIL PROTECTED] PR bootstrap/35218 * Makefile.in (build_file_translate): New. (gcc-vers.texi): Use it for translating $(abs_srcdir). * config.build (build_file_translate): Set to `CMD //c' on MinGW. * configure.ac (build_file_translate): Substitute it. * configure: Regenerate. This patch breaks native bootstrap on mingw systems that use cygwin1.dll-dependent bash and development tools. As such, that would be a regression against all versions of gcc since at least 2.95.3 I did not see an approval of this patch in GCC-patches. Was it approved off-line? The ' CMD //c' (with 2 slashes preceding the switch rather than the one documented for cmd by Micrsosoft) is a MSYS-ism that causes problems with non-MSYS shells (including cygwin bash, ZSH, and the shell provided by MS in its SFU package) Prior to this patch, GCC bootstrapped just fine (with or without the earlier abs_srcdir patch that broke MSYS build) on mingw using the cygwin bash shell, make and configure. Using cygwin shell rather than the MSYS shell means that DejaGnu testsuite can be run. The last time I checked this was not possible with MSYS. Danny -- Summary: [4.3.0 regression] Bootstrap of mingw32 using non-MSYS sehll broken Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net GCC build triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35273
[Bug bootstrap/35273] [4.3.0 regression] Bootstrap of mingw32 using non-MSYS shell broken
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-02-21 06:53 --- Fix typo in summary -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Summary|[4.3.0 regression] |[4.3.0 regression] |Bootstrap of mingw32 using |Bootstrap of mingw32 using |non-MSYS sehll broken |non-MSYS shell broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35273
[Bug c++/35421] ICE on Valid Code
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-03-03 03:32 --- (In reply to comment #4) A 65,000 line testcase? Seriously? I'll try to make a smaller one. But it most likely won't be small. I think the bug is caused by a VERY large expression used with a constructor within a try-catch. Most likely this is just a stack overflow so really not an interesting testcase. Your testcase works for me if I make gcc with LDFLAGS=-Wl,--stack=0x200 Thanks, Andrew Pinski -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added CC||dannysmith at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35421
[Bug target/35054] No documentation of #pragma push_macro(macro_name)
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-03-13 07:08 --- Fixed for 4.4.0 -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35054
[Bug bootstrap/25502] Werror problem in build
--- Comment #12 from dannysmith at users dot sourceforge dot net 2008-03-19 21:35 --- (In reply to comment #11) (In reply to comment #10) Still, 4.3.0 can't recoginze %I64d And that is because it is just being added: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01109.html Even with that patch, we still get ISO C does not support the 'I64' printf length modifier warnings because of --predantic. IMO, that warning is valid and useful and should not be fixed. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25502
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #3 from dannysmith at users dot sourceforge dot net 2008-04-13 09:39 --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01048.html -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot |dot org |sourceforge dot net Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-13 09:39:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug target/35921] Con/de-structor definition fails to override dllimport declaration
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-04-16 01:54 --- (In reply to comment #5) 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. I'll wait a week to see if it causes any problems on trunk, then apply to 4.3 branch. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35921
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #2 from dannysmith at users dot sourceforge dot net 2008-04-26 03:17 --- (In reply to comment #1) What is the status on this? Does reverting the langhooks.c change remanifest PR27067? No. PR27067 is fixed by cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #4 from dannysmith at users dot sourceforge dot net 2008-04-26 07:23 --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #1) What is the status on this? Does reverting the langhooks.c change remanifest PR27067? No. PR27067 is fixed by cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name. I see; then should the langhooks.c bit be reverted to fix this bug, or do you think it will be able to be solved soon some other way? I don't know how to solve it. I thought it might be a GDB bug concerning DW_AT_MIPS_linkage_name and an assumption by GDB that C assembler names are not mangled, but I haven't had time to follow up. But on windows, the external DECL_ASSEMBLER_NAME for stdcall symbols look mangled to me, in C as well as C++, and gcc/dwarf2out.c:add_name_and_src_coords_attributes() does the right thing. But ,as I said, I haven't had time to study GDB. Danny I -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #5 from dannysmith at users dot sourceforge dot net 2008-04-26
08:24 ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
What is the status on this? Does reverting the langhooks.c change
remanifest
PR27067?
No. PR27067 is fixed by
cp/mangle.c (mangle_decl): Call targetm.mangle_decl_assembler_name.
I see; then should the langhooks.c bit be reverted to fix this bug, or do
you
think it will be able to be solved soon some other way?
I don't know how to solve it. I thought it might be a GDB bug concerning
DW_AT_MIPS_linkage_name and an assumption by GDB that C assembler names are
not mangled, but I haven't had time to follow up. But on windows, the
external
DECL_ASSEMBLER_NAME for stdcall symbols look mangled to me, in C as well as
C++, and gcc/dwarf2out.c:add_name_and_src_coords_attributes() does the right
thing.
But ,as I said, I haven't had time to study GDB.
Danny
Huh, it is quite easy to ensure the old gdb assumptions about GNU C
name mangling.
This fixes the PR testcase for me, with GNU gdb 6.5.50.20060706-cvs
(cygwin-special). GCC make check is in progress.
* dwarf2out.c (is c): New function.
(add_name_and_src_coords_attributes): Don't add
DW_AT_MIPS_linkage_name if is_c ().
Index: dwarf2out.c
===
--- dwarf2out.c (revision 134429)
+++ dwarf2out.c (working copy)
@@ -5558,6 +5558,15 @@
return a ? AT_file (a) : NULL;
}
+/* Return TRUE if the language is C. */
+static inline bool
+is_c (void)
+{
+ unsigned int lang = get_AT_unsigned (comp_unit_die, DW_AT_language);
+
+ return (lang == DW_LANG_C || lang == DW_LANG_C89 || lang == DW_LANG_C99);
+}
+
/* Return TRUE if the language is C or C++. */
static inline bool
@@ -11558,7 +11567,7 @@
DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl)
!DECL_ABSTRACT (decl)
!(TREE_CODE (decl) == VAR_DECL DECL_REGISTER (decl))
- !is_fortran ())
+ !is_fortran () !is_c ())
add_AT_string (die, DW_AT_MIPS_linkage_name,
IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
}
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
CC||dannysmith at users dot
||sourceforge dot net
AssignedTo|unassigned at gcc dot gnu |dannysmith at users dot
|dot org |sourceforge dot net
Status|NEW |ASSIGNED
Known to fail||4.3.0
Known to work||4.2.1
Last reconfirmed|2008-04-26 04:13:31 |2008-04-26 08:24:46
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
[Bug testsuite/36057] New: struct-layout-1_generate.c uses non-standard '%n$' operand number formats
This commit
2008-02-20 Uros Bizjak [EMAIL PROTECTED]
* g++.dg/compat/struct-layout-1_generate.c (DG_OPTIONS): New define.
(switchfiles): Use DG_OPTIONS. Explicitly name arguments in fprintf
templates to reduce number of passed arguments.
breaks the G++ struct-layout tests on MS Windows since the host printf family
does not support the '%n$' extension. The dg-options in generated files
look like
/* { dg-options -w $s -I$s } */
After reverting that patch all 150 tescase succeed.
--
Summary: struct-layout-1_generate.c uses non-standard '%n$'
operand number formats
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36057
[Bug debug/33155] _stdcall assembler names in win32 vs gdb
--- Comment #6 from dannysmith at users dot sourceforge dot net 2008-04-26 22:29 --- Patch submitted at http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01977.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33155
