Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make
On 06/05/2013 17:41, Jason Merrill wrote: On 05/05/2013 09:57 AM, Dave Korn wrote: This sounds like a bad idea to me, and not just because the locking mechanism is dodgy. Is the problem more widespread than just your laptop? Does it affect other host OSs? Linking multiple frontends at once doesn't lock up my desktop PC, so I'd rather not have it disabled. Part of the issue is that I build with -g3, which greatly increases the memory consumption at link time. And builds are sharing 4GB with everything else I want to run. I would be happy to have the mechanism off by default and manually enabled by people in my situation. Well I couldn't possibly object to that :) Why don't you just nice your build shell? Shouldn't that make the rest of your system responsive? I don't think that helps much with swap thrashing, though I could be wrong. Ah, no, you're probably right there. So serialising those final links sounds like a reasonable solution. cheers, DaveK
Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make
On 01/05/2013 03:02, Jason Merrill wrote: Since GNU Make doesn't support anything like the .MUTEX directive (http://savannah.gnu.org/bugs/?func=detailitemitem_id=17873), and accidentally doing make -j8 -l4 makes my laptop useless for several minutes while it tries to link all the front ends at once, I decided to kludge a workaround. This hack uses mkdir as a locking mechanism, as it fails if the directory already exists. Each front-end rule first tries to get the lock, and spins if the lock isn't available. Currently I'm enabling the locking by default on build hosts with less than 8GB of memory. Releasing the lock is not reliable; if the user interrupts the link with ^C, the lock will remain. So I adjusted 'make all' to remove the lock early on, though that only works for the typical case, and users that do something like 'make cc1plus' could still run into trouble. Thoughts? Is this too horrible a hack, or does it seem like something we might want? Maybe I should fix Make instead. This sounds like a bad idea to me, and not just because the locking mechanism is dodgy. Is the problem more widespread than just your laptop? Does it affect other host OSs? Linking multiple frontends at once doesn't lock up my desktop PC, so I'd rather not have it disabled. Why don't you just nice your build shell? Shouldn't that make the rest of your system responsive? cheers, DaveK
Re: Failure building current snapshot [Cygwin]
On 22/04/2013 13:51, Angelo Graziosi wrote: Il 16/04/2013 10.10, Dave Korn ha scritto: This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 From comment 5 and 9 something should be fixed but with current snapshot, 4.9-20130421, it seems that the build fails in the same way: Nothing's been checked in yet. Tests look good though, so we should be able to proceed soon. cheers, DaveK
Re: LRA assign same hard register with live range overlapped pseduos
On 18/04/2013 21:50, Vladimir Makarov wrote: On 04/17/2013 11:18 PM, Shiva Chen wrote: Full test2.c.209r.reload is about 296kb and i can't send successfully. Is there another way to send the dump file? Did you try to compress it? Another possibility would be send dump only for the particular function. And there's always pastebin.com cheers, DaveK
Re: Failure building current snapshot [Cygwin]
On 15/04/2013 15:50, Angelo Graziosi wrote: The current snapshot [*] fails to build on Cygwin as follow: /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c: In function ‘__gcc_register_frame’: /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:106:19: warning: array subscript is above array bounds [-Warray-bounds] if (__JCR_LIST__[0]) ^ /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: error: unrecognizable insn: } ^ (insn 15 14 16 5 (set (reg:SI 63) (symbol_ref:SI (GetModuleHandleA@4) [flags 0x441] function_decl 0x7f988e00 GetModuleHandleA)) /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:109 -1 (nil)) /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: internal compiler error: in extract_insn, at recog.c:2150 /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: internal compiler error: Aborted xgcc: internal compiler error: Aborted (program cc1) Please submit a full bug report, with preprocessed source if appropriate. Had a report similar to this offlist last week, suggested it was fallout from Kai's 64-bit patches. Trying to repro now, please file a PR and CC me and Kai. cheers, DaveK
Re: Failure building current snapshot [Cygwin]
On 16/04/2013 07:05, Dave Korn wrote: On 15/04/2013 15:50, Angelo Graziosi wrote: /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: error: unrecognizable insn: } ^ (insn 15 14 16 5 (set (reg:SI 63) (symbol_ref:SI (GetModuleHandleA@4) [flags 0x441] function_decl 0x7f988e00 GetModuleHandleA)) ix86_legitimate_address_p fails on (symbol_ref:SI (GetModuleHandleA@4) [flags 0x441] function_decl 0x7fb9b600 GetModuleHandleA). I suspect that isn't helpful. cheers, DaveK
Re: Failure building current snapshot [Cygwin]
On 16/04/2013 07:55, Dave Korn wrote: On 16/04/2013 07:05, Dave Korn wrote: On 15/04/2013 15:50, Angelo Graziosi wrote: /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: error: unrecognizable insn: } ^ (insn 15 14 16 5 (set (reg:SI 63) (symbol_ref:SI (GetModuleHandleA@4) [flags 0x441] function_decl 0x7f988e00 GetModuleHandleA)) ix86_legitimate_address_p fails on (symbol_ref:SI (GetModuleHandleA@4) [flags 0x441] function_decl 0x7fb9b600 GetModuleHandleA). I suspect that isn't helpful. Oh no wait; that makes sense because it's a dllimport symbol, so not constant. Forget that theory. cheers, DaveK
Re: Failure building current snapshot [Cygwin]
On 15/04/2013 15:50, Angelo Graziosi wrote: The current snapshot [*] fails to build on Cygwin as follow: /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: error: unrecognizable insn: } ^ (insn 15 14 16 5 (set (reg:SI 63) (symbol_ref:SI (GetModuleHandleA@4) [flags 0x441] function_decl 0x7f988e00 GetModuleHandleA)) /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:109 -1 (nil)) /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: internal compiler error: in extract_insn, at recog.c:2150 /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1: internal compiler error: Aborted xgcc: internal compiler error: Aborted (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 cheers, DaveK
Re: [Patch, fortran] PR 56919 SYSTEM_CLOCK on Windows
On 12/04/2013 19:47, Janne Blomqvist wrote: As I don't have a Windows system to test on, I would appreciate if somebody more familiar with that platform could take a quick look. In particular, I *think* it should be Ok to use win32 API functions on Cygwin (that is, cygwin-gcc ships the windows.h and other necessary headers out of the box?), Well, after installing the w32api package, but basically yes, that's fine for simple stuff like that. (You shouldn't go doing things like creating threads or synchronisation through the Win32 API, but calling GetTickCount[64] will be fine.) and that _WIN32 is the correct macro to use to select code which is common to MinGW and Cygwin. Alas no: $ gcc-4 -E - /dev/null -dM | grep WIN #define __WINT_MAX__ 4294967295U #define __WINT_MIN__ 0U #define __SIZEOF_WINT_T__ 4 #define __CYGWIN__ 1 #define __WINT_TYPE__ unsigned int #define __CYGWIN32__ 1 You should probably use #if defined(__MINGW32__) || defined (__CYGWIN__), since that'll also work on 64-bit Cygwin, as opposed to using __CYGWIN32__. I think __MINGW32__ is defined for 64-bit as well as 32-bit targets. cheers, DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 09/04/2013 11:37, Kai Tietz wrote: Hmm, well in standard-case you are right. But well there is still a chance that GetProcAddress returns NULL-pointer ... How would that actually happen? Removing any of those functions from libgcc or libjava would be a very serious ABI breakage; we're never going to do that. (And even if we do, the version number of the DLL would have to change and LoadLibrary wouldn't return anything, unless we changed the shared lib string, which would be the appropriate time to re-add a check.) It's not critical, but it's wasted code. cheers, DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 22/03/2013 08:44, Kai Tietz wrote:
2013-03-22 Kai Tietz kti...@redhat.com
* config/i386/cygming-crtbegin.c (__register_frame_info): Make weak.
(__deregister_frame_info): Likewise.
Hi Kai,
I read your explanation of the problem relating to x86-64 memory models over
on the Cygwin dev list, and that explained your motivation for making this
change; I see why it's not easy to get an *ABS* 0 reference there. So,
providing dummy versions of the functions makes perfect sense to me, and
certainly won't cause problems for i686. (I did a lot of testing, and the
only problem I found is that a weak definition has to be provided on the
linker command line *after* the file that contains the weak-with-zero-default
definition if it is to override that; in the case here however we're going to
be overriding the weak-with-default by a strong function declaration, so that
issue does not arise.)
I still have a comment or two about the patch itself:
Index: libgcc/config/i386/cygming-crtbegin.c
===
--- libgcc/config/i386/cygming-crtbegin.c (Revision 196898)
+++ libgcc/config/i386/cygming-crtbegin.c (Arbeitskopie)
@@ -46,15 +46,33 @@ see the files COPYING3 and COPYING.RUNTIME respect
#define LIBGCJ_SONAME libgcj_s.dll
#endif
-
+#if DWARF2_UNWIND_INFO
/* Make the declarations weak. This is critical for
_Jv_RegisterClasses because it lives in libgcj.a */
-extern void __register_frame_info (const void *, struct object *)
+extern void __register_frame_info (__attribute__((unused)) const void *,
+__attribute__((unused)) struct object *)
TARGET_ATTRIBUTE_WEAK;
-extern void *__deregister_frame_info (const void *)
+extern void *__deregister_frame_info (__attribute__((unused)) const void *)
TARGET_ATTRIBUTE_WEAK;
-extern void _Jv_RegisterClasses (const void *) TARGET_ATTRIBUTE_WEAK;
+TARGET_ATTRIBUTE_WEAK void
+__register_frame_info (__attribute__((unused)) const void *p,
+__attribute__((unused)) struct object *o)
+{}
Braces should go on separate lines I think.
+TARGET_ATTRIBUTE_WEAK void *
+__deregister_frame_info (__attribute__((unused)) const void *p)
+{ return (void*) 0; }
Certainly here.
+#endif /* DWARF2_UNWIND_INFO */
+
+#if TARGET_USE_JCR_SECTION
+extern void _Jv_RegisterClasses (__attribute__((unused)) const void *)
+ TARGET_ATTRIBUTE_WEAK;
+
+TARGET_ATTRIBUTE_WEAK void
+_Jv_RegisterClasses (__attribute__((unused)) const void *p)
+{}
+#endif /* TARGET_USE_JCR_SECTION */
+
#if defined(HAVE_LD_RO_RW_SECTION_MIXING)
# define EH_FRAME_SECTION_CONST const
#else
Also, now that you've provided a default weak definition of the functions in
the file itself, it's no longer possible for the function pointer variables
(register_frame_fn, register_class_fn, deregister_frame_fn) to be zero, so you
should remove the if () tests on them and just call them unconditionally.
cheers,
DaveK
Re: Intentional or accidental backward-incompatibility w.r.t. process attributes?
On 04/04/2013 08:48, Kai Tietz wrote: Hi Kai, That change is intentional and would be called __thiscall.nbsp; To mix stdcall and regparam is no more supported AFAIK. Why are stdcall and regparam not allowed together any more? They seem entirely orthogonal to me, and the overall result is effectively to place an arbitrary limit of 1 (the hidden this pointer) on the number of parameters that can be passed in registers. If I change __stdcall to __thiscall in the example, I get a clear error message: bar.h:3:57: error: regparam and thiscall attributes are not compatible However in the original case the error message about ambiguates old declaration is unclear: a) it doesn't say what the problem is, b) it goes away if you repeat the regparm attribute on the function definition and appears to compile correctly, generating what looks like valid assembly to me. cheers, DaveK
Intentional or accidental backward-incompatibility w.r.t. process attributes?
Hi list,
Previously (tested with gcc-4.5.3), constructs like this:-
-- foo.h
struct sigpacket
{
int __stdcall process () __attribute__ ((regparm (1)));
};
-- foo.cpp
#include foo.h
int __stdcall
sigpacket::process ()
{
return 2;
}
--
... used to work, with the attribute from the declaration being applied also
to the definition.
$ g++-4 --version
g++-4 (GCC) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4 -W -Wall -c foo.cc -o foo.o
With = gcc-4.7, this results in an error:
$ /usr/bin/g++-4 --version
g++-4 (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/bin/g++-4 -W -Wall -c foo.cc -o foo.o
foo.cc:4:21: error: new declaration 'int sigpacket::process()'
In file included from foo.cc:1:0:
foo.h:3:17: error: ambiguates old declaration 'int sigpacket::process()'
$
I can't find any reference to this changed behaviour in the 4.7 or 4.8
changes.html; was it intentional?
cheers,
DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 22/03/2013 08:44, Kai Tietz wrote: Hi, this change is actual used by cygwin and is required for upcoming x64 cygwin target. ChangeLog 2013-03-22 Kai Tietz kti...@redhat.com * config/i386/cygming-crtbegin.c (__register_frame_info): Make weak. (__deregister_frame_info): Likewise. Tested for i686-pc-cygwin, and x86_64-pc-cygwin. I will apply this code tomorrow if there are no objections by other Windows-target-maintainers. I don't think the ChangeLog entry is right; it doesn't make the declarations weak, it supplies definitions. Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? cheers, DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 22/03/2013 09:00, Kai Tietz wrote: (LIBGCJ_SONAME): Make name minor-build-version dependent. Tested for i686-pc-cygwin, and x86_64-pc-cygwin. Dave, please especially a look to LIBGCJ_SONAME change. I think we should include MAJOR_VERSION here, too. Ok for apply? I'm not sure about it: -/* We should find a way to not have to update this manually. */ -#define LIBGCJ_SONAME cyggcj /*LIBGCC_EH_EXTN*/ -13.dll - +#ifndef BUILDING_GCC_MAJOR +#include bversion.h +#endif +#define ___cyg_mkstr(x) #x +#define __cyg_mkstr(x) ___cyg_mkstr(x) +#if BUILDING_GCC_MAJOR == 4 +#define LIBGCJ_SONAME cyggcj- __cyg_mkstr (BUILDING_GCC_MINOR+6) .dll +#else +#error LIBGCJ_SONAME versioning scheme needs attention +#endif AIUI, the libgcj soversion has no fixed relation to the GCC major/minor version of necessity, but is specified by the parameters in $srcdir/libjava/libtool-version, which is manually updated. We really ought to run a script to extract the version info fields from there and do the calculation ourselves if we're going to try to automate it. Even if it is policy to bump the libgcj soversion with every minor release of GCC, there's no use us having the right value if someone neglects to update libjava; only generating it from the libjava file will guarantee everything stays in absolute lockstep. cheers, DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 22/03/2013 09:00, Kai Tietz wrote: (CXX_WRAP_SPEC_LIST): Undefine before define. @@ -73,6 +82,7 @@ /* To implement C++ function replacement we always wrap the cxx malloc-like operators. See N2800 #17.6.4.6 [replacement.functions] */ +#undef CXX_WRAP_SPEC_LIST #define CXX_WRAP_SPEC_LIST \ --wrap _Znwj \ --wrap _Znaj \ Also, I don't think this is really necessary. Isn't it the case that cygwin.h provides base definitions, and cygwin-w64.h overrides them, and it would always be an error to include cygwin-w64.h before cygwin.h? In which case the macro redefinition error would be a useful warning that somebody was using the headers wrong. cheers, DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 23/03/2013 00:08, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? Well, weak undefs are possible with pe-coff. We ran into that by porting cygwin to x64. But you are right that pe-coff doesn't support undefines (weak or none-weak) within final-link, so for a weak we need always a default implementation. This we added here. I thought it does (support weak undefines within final link). Weak references with no definition resolve to zero, no? cheers, DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. cheers, DaveK
Re: [patch]: Add configure and required host/target definitions for new cygwin x64 target
On 22/03/2013 09:56, Kai Tietz wrote:
Hi,
this patch adds required configure changes for new cygwin x64 target.
Index: gcc/configure.ac
===
--- gcc/configure.ac (Revision 196898)
+++ gcc/configure.ac (Arbeitskopie)
@@ -3623,7 +3623,7 @@ changequote([,])dnl
# wrappers to aid in interposing and redirecting operators new, delete,
# etc., as per n2800 #17.6.4.6 [replacement.functions]. Check if we
# are configuring for a version of Cygwin that exports the wrappers.
- if test x$host = x$target; then
+ if test x$host = x$target test x$host_cpu = xi686; then
AC_CHECK_FUNC([__wrap__Znaj],[gcc_ac_cygwin_dll_wrappers=yes],[gcc_ac_cygwin_dll_wrappers=no])
else
# Can't check presence of libc functions during cross-compile, so
Rather than just bailing on x86_64, shouldn't this code check for the
presence of one of the 64-bit versions of the C++ wrapper functions such as
__wrap__Znam instead?
Index: libgcc/config.host
===
--- libgcc/config.host(Revision 196898)
+++ libgcc/config.host(Arbeitskopie)
@@ -564,13 +564,30 @@ i[34567]86-*-cygwin*)
tmake_eh_file=i386/t-dw2-eh
fi
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
I don't get this. We're compiling a target library, so only build and host
are correct to use, AIUI; $target may still be set by accident, but it's not
meaningful when building a target lib.
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
Same here.
cheers,
DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 23/03/2013 00:24, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. cheers, DaveK Right, but shouldn't that be done by libjava-DLL itself on loading (and deregistration on unloading)? I see no good point to add this into a different dll? But well, I might miss here an important point. Well, libgcc is always there, and libjava doesn't have any specific hooks where we could add startup code, which is why all targets do it by default in libgcc/crtstuff.c along with the C++ default ctor stuff. cheers, DaveK
Re: [patch libgcc]: Adjust cygming-crtbegin code to use weak
On 23/03/2013 00:27, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:08, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: Also, can you explain the motivation for this change? I don't see how it's going to work right; from what I remember, we don't have weak definitions in PE-COFF, just weak references. How does the correct definition get chosen when we may have two definitions in a final link? Well, weak undefs are possible with pe-coff. We ran into that by porting cygwin to x64. But you are right that pe-coff doesn't support undefines (weak or none-weak) within final-link, so for a weak we need always a default implementation. This we added here. I thought it does (support weak undefines within final link). Weak references with no definition resolve to zero, no? No, actual they aren't zero value, they are reported as undefined symbol, which seems to me from perpective of pe-coff weak definition the right thing to do. I think something's going wrong. From the PE-COFF specs: “Weak externals” are a mechanism for object files that allows flexibility at link time. A module can contain an unresolved external symbol (sym1), but it can also include an auxiliary record that indicates that if sym1 is not present at link time, another external symbol (sym2) is used to resolve references instead. If a definition of sym1 is linked, then an external reference to the symbol is resolved normally. If a definition of sym1 is not linked, then all references to the weak external for sym1 refer to sym2 instead. The external symbol, sym2, must always be linked; typically, it is defined in the module that contains the weak reference to sym1. In gcc/binutils, what we do is automatically provide an aux record (sym2) with the value *ABS* zero. If a definition (strong, because we only have strong definitions in PE-COFF) of the weakly-referenced symbol is provided, that overrides the aux value of zero, but otherwise the zero value is used. IIRC, there's a binutils bugzilla entry about things not going well if two strong definitions are provided to resolve a weak external. I'll try and dig it up. cheers, DaveK
Re: [patch]: Add configure and required host/target definitions for new cygwin x64 target
On 23/03/2013 00:41, Kai Tietz wrote:
2013/3/23 Dave Korn dave.korn.cyg...@gmail.com:
On 22/03/2013 09:56, Kai Tietz wrote:
Hi,
this patch adds required configure changes for new cygwin x64 target.
Index: gcc/configure.ac
===
--- gcc/configure.ac (Revision 196898)
+++ gcc/configure.ac (Arbeitskopie)
@@ -3623,7 +3623,7 @@ changequote([,])dnl
# wrappers to aid in interposing and redirecting operators new,
delete,
# etc., as per n2800 #17.6.4.6 [replacement.functions]. Check if we
# are configuring for a version of Cygwin that exports the wrappers.
- if test x$host = x$target; then
+ if test x$host = x$target test x$host_cpu = xi686; then
AC_CHECK_FUNC([__wrap__Znaj],[gcc_ac_cygwin_dll_wrappers=yes],[gcc_ac_cygwin_dll_wrappers=no])
else
# Can't check presence of libc functions during cross-compile, so
Rather than just bailing on x86_64, shouldn't this code check for the
presence of one of the 64-bit versions of the C++ wrapper functions such as
__wrap__Znam instead?
Sure, this should be a follow-up patch. For now we should get initial
version into repository. There are some other places we need to visit
later, too.
Ok, fair enough.
Index: libgcc/config.host
===
--- libgcc/config.host(Revision 196898)
+++ libgcc/config.host(Arbeitskopie)
@@ -564,13 +564,30 @@ i[34567]86-*-cygwin*)
tmake_eh_file=i386/t-dw2-eh
fi
# Shared libgcc DLL install dir depends on cross/native build.
- if test x${build} = x${host} ; then
+ if test x${host} = x${target} ; then
I don't get this. We're compiling a target library, so only build and host
are correct to use, AIUI; $target may still be set by accident, but it's not
meaningful when building a target lib.
Well, I think the idea here was that cygwin installs anyway
(especially for candian-cross AFAIR) into native (bin/) location.
That's a kludge.
Eh? The whole point of this bit is to avoid installing into the native
location in any kind of cross build. This was the fix for PR40125; the libgcc
equivalent of $srcdir/config/lthostflags.m4.
cheers,
DaveK
Re: [patch cygwin64]: Add and adjust some initial sources for x64 cygwin
On 23/03/2013 00:57, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:24, Kai Tietz wrote: 2013/3/23 Dave Korn dave.korn.cyg...@gmail.com: On 23/03/2013 00:16, Kai Tietz wrote: welcome, too. It would be even better if we could rethink actual the need of loading java-library within libgcc's cygwin's/mingw's crtbegin at all. I am actual not that sure, if we need this at all. Somebody has to register the default classes at startup, or attempts to classload them will fail. Right, but shouldn't that be done by libjava-DLL itself on loading (and deregistration on unloading)? I see no good point to add this into a different dll? But well, I might miss here an important point. Well, libgcc is always there, and libjava doesn't have any specific hooks where we could add startup code, which is why all targets do it by default in libgcc/crtstuff.c along with the C++ default ctor stuff. Hmm, we have DllMain. it is enough for native Windows. And cygwin has same feature via DECLARE_CYGWIN_DLL( DllMain ); AFAIK. Well, yes we do, but why not just do it the same way every other target does it? Also, DllMain is very risky to do anything complex in. Without having some strong guarantees about how the default java class registration code might or might not behave, I don't want to call it from DllMain. (You've read http://www.microsoft.com/whdc/driver/kernel/DLL_bestprac.mspx?) cheers, DaveK
Re: GCC 4.8.0 Release Candidate available from gcc.gnu.org
On 16/03/2013 11:57, Jakub Jelinek wrote: GCC 4.8.0 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.8.0 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.0-RC-20130316 and shortly its mirrors. It has been generated from SVN revision 196699. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. Built (all but ada) and tested C/C++ on i686-pc-cygwin, looks OK at first glance but results somewhat obfuscated by some noise from the testsuite. cheers, DaveK
Seemingly bogus FAILs in g++ testsuite.
Hi list,
I'm in the middle of a testsuite run and just saw the following FAILs crop up:
FAIL: g++.old-deja/g++.brendan/cvt1.C (test for excess errors)
FAIL: g++.old-deja/g++.brendan/enum11.C (test for excess errors)
FAIL: g++.old-deja/g++.brendan/enum8.C (test for excess errors)
FAIL: g++.old-deja/g++.brendan/enum9.C (test for excess errors)
FAIL: g++.old-deja/g++.brendan/friend3.C (test for excess errors)
They all result from the same kind of error message, e.g.:
/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/cvt1.C
/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/cvt1.C:8:43: error: comma
at end of enumerator list [-Wpedantic]
/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/cvt1.C:18:44: error:
comma at end of enumerator list [-Wpedantic]
compiler exited with status 1
output is:
/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/cvt1.C:8:43: error: comma
at end of enumerator list [-Wpedantic]
/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/cvt1.C:18:44: error:
comma at end of enumerator list [-Wpedantic]
FAIL: g++.old-deja/g++.brendan/cvt1.C (test for excess errors)
Excess errors:
/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/cvt1.C:8:43: error: comma
at end of enumerator list [-Wpedantic]
/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/cvt1.C:18:44: error:
comma at end of enumerator list [-Wpedantic]
Which is strange in two regards, because:
$ cat -n /gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.brendan/enum11.C
1 // { dg-do assemble }
2 // GROUPS passed enums
3 class X
4 {
5 enum
6 {
7 oneMask = 0x,
8 twoMask = 0x000F,
9 thiMask = 0xFFF0, // { dg-error comma at end { target
c++98 } }
10 };
11 unsigned int foo;
12
13 public:
14 X (int) : foo (oneMask | twoMask ) {} // No warning
15 X (): foo (oneMask | twoMask | thiMask) {} // Warning
16 };
#1: Line 8 isn't the end of the enum list; line #9 is and it's correctly
tagged with dg-error
#2: There aren't even 18 lines in the source.
This doesn't appear to be happening on Linux (I'm using i686-pc-cygwin), so
is there some target-dependent support for the new error carets that needs
adding? (I'd guess not, and anyway, how would that turn one error into two,
but asking nonetheless). Has anyone else seen anything like this or got some
idea what might be going wrong?
cheers,
DaveK
Re: [PATCH][4.8][4.7][4.6] Make -shared-libgcc the default on Cygwin.
On 12/03/2013 08:59, Richard Biener wrote: On Tue, Mar 12, 2013 at 2:44 AM, Dave Korn dave.korn.cyg...@gmail.com wrote: Hello list, The attached patch makes -shared-libgcc the default for Cygwin. This is something that I should have done some time ago, as shared libgcc on Cygwin is more than mature. What's more, it is vital for reliable compilation of applications that throw exceptions or share TLS variables from DLLs into the main executable; at present these compile incorrectly without an explicit -shared-libgcc. For instance, the just-released MPFR-3.1.2 doesn't work without it. Given that it's a very simple tweak to the compiler specs on a single platform only, I would like to use my target maintainer's discretion to apply it even at this late stage, but I figure it's so close to RC1 that I should ask the RM's permission anyway. I'd also like to backport it to all the currently-open branches. gcc/ChangeLog 2013-03-12 Dave Korn dave.korn.cygwin@ * config/i386/cygwin.h (SHARED_LIBGCC_SPEC): Make shared libgcc the default setting. Is this OK by everyone? Ok for trunk (4.8). Please add a documentation entry to gcc-4.8/changes.html. Committed revision 196634, with the attached documentation update and cvs log entry: * htdocs/gcc-4.8/changes.html: Add OS-specific section and entry for Windows (Cygwin). I'm not sure whether this kind of stuff should change on a release branch, I'll defer to others for this. Still, if you backport it, add a gcc-4.x/changes.html item to the sub-release sections. Would still like to do this, as it's important for correctness in anything that links against shared libraries, and it'll only have to be maintained as a local patch to any Cygwin distro version of GCC if we don't. cheers, DaveK Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.105 diff -p -u -r1.105 changes.html --- htdocs/gcc-4.8/changes.html 27 Feb 2013 19:24:43 - 1.105 +++ htdocs/gcc-4.8/changes.html 13 Mar 2013 15:19:44 - @@ -805,6 +805,20 @@ B b(42); // OK command-line option./li /ul +h2 id=osOperating Systems/h2 + +h3 id=windowsWindows (Cygwin)/h3 + ul +liExecutables are now linked against shared libgcc by default. +The previous default was to link statically, which can still be +done by explicitly specifying -static or -static-libgcc on the +command line. However it is strongly advised against, as it +will cause problems for any application that makes use of DLLs +compiled by GCC. It should be alright for a monolithic stand-alone +application that only links against the Windows OS DLLs, but +offers little or no benefit./li + /ul + !-- h2Documentation improvements/h2 --
[PATCH][4.8][4.7][4.6] Make -shared-libgcc the default on Cygwin.
Hello list,
The attached patch makes -shared-libgcc the default for Cygwin. This is
something that I should have done some time ago, as shared libgcc on Cygwin is
more than mature. What's more, it is vital for reliable compilation of
applications that throw exceptions or share TLS variables from DLLs into the
main executable; at present these compile incorrectly without an explicit
-shared-libgcc. For instance, the just-released MPFR-3.1.2 doesn't work
without it.
Given that it's a very simple tweak to the compiler specs on a single
platform only, I would like to use my target maintainer's discretion to apply
it even at this late stage, but I figure it's so close to RC1 that I should
ask the RM's permission anyway.
I'd also like to backport it to all the currently-open branches.
gcc/ChangeLog
2013-03-12 Dave Korn dave.korn.cygwin@
* config/i386/cygwin.h (SHARED_LIBGCC_SPEC): Make shared libgcc the
default setting.
Is this OK by everyone?
cheers,
DaveK
Index: gcc/config/i386/cygwin.h
===
--- gcc/config/i386/cygwin.h (revision 196604)
+++ gcc/config/i386/cygwin.h (working copy)
@@ -48,11 +48,7 @@ along with GCC; see the file COPYING3. If not see
%{static|static-libgcc:-lgcc -lgcc_eh} \
%{!static: \
%{!static-libgcc: \
- %{!shared: \
- %{!shared-libgcc:-lgcc -lgcc_eh} \
- %{shared-libgcc:-lgcc_s -lgcc} \
- } \
- %{shared:-lgcc_s -lgcc} \
+ -lgcc_s -lgcc \
} \
}
#else
Re: [PATCH, updated] Vtable pointer verification, runtime library changes (patch 3 of 3)
On 08/03/2013 00:11, Jonathan Wakely wrote: On 7 March 2013 23:53, Caroline Tice wrote: I believe this patch addresses all of your comments; I modified the configure.ac files to generate the configures, and I fixed the spelling mistakes in the comments. I still get the warnings when generating the Makefile.in files from the Makefile.am files, but the resulting files seem to be correct, and I don't know how to make the warnings go away. Please review this patch and let me know if it will be ok to commit when GCC opens up again. I'd like to know if someone with better automake skills than I have can do anything about that warning, but otherwise that looks OK to me, thanks. Looks like libvtv___la_LIBADD is still being defined in the else clause. I'm also getting warnings for src/c++11/Makefile.am about EXTRA_VTV_LDFLAGS, which may need renaming to avoid confusing automake: src/c++11/Makefile.am:70: variable `EXTRA_VTV_LDFLAGS' is defined but no program or src/c++11/Makefile.am:70: library has `EXTRA_VTV' as canonical name (possible typo) src/c++98/Makefile.am:152: variable `EXTRA_VTV_LDFLAGS' is defined but no program or src/c++98/Makefile.am:152: library has `EXTRA_VTV' as canonical name (possible typo) Also, it should generally contain only .lo and .la object and libraries to link against. From the automake manual: 8.3.7 _LIBADD, _LDFLAGS, and _LIBTOOLFLAGS As shown in previous sections, the ‘library_LIBADD’ variable should be used to list extra libtool objects (‘.lo’ files) or libtool libraries (‘.la’) to add to library. The ‘library_LDFLAGS’ variable is the place to list additional libtool linking flags, such as ‘-version-info’, ‘-static’, and a lot more. So putting a dir path into LIBADD and then concatenating -L and including it wholesale in some other flag variable seems incorrect. Also, both that and the top-level change looks dubious to me. The libtool subdir isn't necessarily called '.libs' on all platforms, and you should never need to reach into it(*). Likewise LIBVTV_FLAGS. Instead of adding -lvtv_init or -lvtv_stubs to the linker flags, I think you're supposed to add the corresponding .la files to the relevant LIBADD variable. And w.r.t. the top-level change, I think it may turn out to be unneeded altogether once the libtool stuff is correct. It also looks odd to me that linker flags are being added into a CXXFLAGS variable (EXTRA_VTV_LDFLAGS via VTV_CXXFLAGS) rather than the corresponding LDFLAGS. I'm not a libtool expert, I've just been told to avoid similar dubious practices in patches I've submitted in the past. And one minor nit, it is conventional not to include the generated files (Makefile.in, configure) in patches. They should autogenerate exactly the same everywhere and it saves clutter. cheers, DaveK -- (*) - I see a couple of cases have slipped through already, I think we should avoid adding any more.
Re: GCC 4.8.0 Status Report (2013-03-06)
On 06/03/2013 16:05, Jakub Jelinek wrote: If no new P1 appears within a week, I may be about to file one. What priority would Java doesn't compile on a secondary platform count as? There's a trivial bug in libffi and I already posted a patch(*) to both -patches and upstream, but am waiting for a response. cheers, DaveK -- (*) - http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01030.html
Re: GCC 4.8.0 Status Report (2013-03-06)
On 07/03/2013 16:55, Andrew Haley wrote: On 03/07/2013 02:09 PM, Dave Korn wrote: On 06/03/2013 16:05, Jakub Jelinek wrote: If no new P1 appears within a week, I may be about to file one. What priority would Java doesn't compile on a secondary platform count as? There's a trivial bug in libffi and I already posted a patch(*) to both -patches and upstream, but am waiting for a response. Anthony approved it already on Feb 21. Ah, I may have missed a point there. Does AG's approval apply to gcc's copy of libffi? He said he thought I should commit to gcc/libffi independently, but I thought I would need someone else's approval for that. I see now that there is no gcc-specific libffi maintainer listed in MAINTAINERS, so I should just go ahead and commit? cheers, DaveK
Re: GCC 4.8.0 Status Report (2013-03-06)
On 07/03/2013 21:00, Andrew Haley wrote: Either Anthony or I review libffi patches in gcc. Perhaps you two should list yourselves as such in MAINTAINERS, for the avoidance of doubt? You're not going to get any more reviews. I committed it. Thanks for the clarification. cheers, DaveK
Re: [LIBFFI] Re: Re: [PATCH] Add support for PaX enable kernels (MPROTECT)
On 21/02/2013 19:35, Anthony Green wrote: This patch looks fine, thanks. I don't plan to merge back into GCC for at least a week or two, so I think you should commit it to the GCC tree independently. Committed to GCC revision 196527. Thanks! cheers, DaveK
Re: RFC: add some static probes to libstdc++
On 27/02/2013 21:52, Tom Tromey wrote:
I'm posting this now to get reactions to the probe before cleaning up
the corresponding gdb patches for submission. I've built it both with
and without sys/sdt.h, but I haven't yet run the test suite.
How did it build in the without sys/sdt.h case?
+#ifdef HAVE_SYS_SDT_H
+#include sys/sdt.h
+/* We only want to use stap probes starting with v3. Earlier versions
+ added too much startup cost. */
+#if defined (STAP_PROBE2) _SDT_NOTE_TYPE = 3
+#define PROBE2(name, arg1, arg2) STAP_PROBE2 (libstdcxx, name, arg1, arg2)
+#else
+#define PROBE2(name, arg1, arg2)
+#endif
+#endif
+
Without HAVE_SYS_SDT_H, there's no definition of PROBE2 at all, but you use
it unconditionally in eh_{catch,throw}.cc. Am I missing something?
cheers,
DaveK
Re: [PATCH] Pass LDFLAGS when building libgcc
On 26/02/2013 22:07, Ludovic Courtès wrote: * Makefile.in (LDFLAGS): New variable. Import from automake might be more informative. cheers, DaveK
Re: [PATCH] Pass LDFLAGS when building libgcc
On 27/02/2013 19:53, Ludovic Courtès wrote: Dave Korn skribis: On 26/02/2013 22:07, Ludovic Courtès wrote: * Makefile.in (LDFLAGS): New variable. Import from automake might be more informative. Automake has nothing to do with that. Thinko on my part. It's autoconf (via the generated configure script) that does those substitutions. cheers, DaveK
Re: [PATCH] PR55033: Fix
On 12/02/2013 16:11, Sebastian Huber wrote: This patch from Alan Modra fixes a section type conflict error. See also http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02172.html The Windows part is OK. I ran the g++ testsuite (gcc/, not libstdc) with no change before and after. cheers, DaveK
Re: [LIBFFI] Re: Re: [PATCH] Add support for PaX enable kernels (MPROTECT)
On 21/02/2013 19:35, Anthony Green wrote: On Thu, Feb 21, 2013 at 2:22 PM, Dave Korn wrote: Gcc-patches: Assuming AG approves, can we commit this without waiting for an upstream libffi release and doing a full merge? Currently GCC HEAD won't build libffi (and hence libjava) without it. This patch looks fine, thanks. I don't plan to merge back into GCC for at least a week or two, so I think you should commit it to the GCC tree independently. This means that 3.0.12 is broken for Cygwin. Are you able to produce test results once you apply this change? I should probably issue a quick 3.0.13 if the results are decent. Yes, the tests run fine (using libffi git HEAD from yesterday): Native configuration is i686-pc-cygwin === libffi tests === Running target unix FAIL: libffi.call/closure_thiscall.c (test for excess errors) WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable FAIL: libffi.call/closure_thiscall.c (test for excess errors) WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable FAIL: libffi.call/closure_thiscall.c (test for excess errors) WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable FAIL: libffi.call/closure_thiscall.c (test for excess errors) WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable FAIL: libffi.call/closure_thiscall.c (test for excess errors) WARNING: libffi.call/closure_thiscall.c compilation failed to produce executable === libffi Summary === # of expected passes1924 # of unexpected failures5 I was using gcc-4.5.3, which is from before thiscall support was added, so those compile failures are unremarkable and expected. Given that, we have a clean sweep. cheers, DaveK
[LIBFFI] Re: Re: [PATCH] Add support for PaX enable kernels (MPROTECT)
On 07/11/2012 00:14, Magnus Granberg wrote: 2012-11-07 Magnus Granberg zorry@gentoo... Pavel Labushev pavel.labushev@runbox... * configure.ac: Add --enable-pax_emutramp for PaX enable kernels. * src/closures.c: Add emutramp_enabled_check. Don't mmap with PROT_EXEC on PaX enable Kernels. * README: Add description for --enable-pax_emutramp. * fficonfig.h.in: Rebuilt. * configure.ac: Rebuilt. Hi lists, There was a small problem with this (upstream relative to gcc) libffi patch(*). The entire #ifdef FFI_MMAP_EXEC_EMUTRAMP_PAX clause is contained within an outer #if !defined(X86_WIN32) !defined(X86_WIN64) clause. That means that Windows platforms don't get the default definition of is_emutramp_enabled() supplied by the #else clause. However, is_emutramp_enabled() is unconditionally referenced in dlmmap(), and without this default definition Windows targets fail to compile. The attached patch fixes this by moving the #else clause with the default is_emutramp_enabled() definition to a standalone #ifndef clause outside any enclosing conditional compilation test. I couldn't think of a better way to do it; the #if !(windows) clause is followed by a #elif (cygwin/interix) clause, so I'd have had to put a default definition in there and also a second one in a subsequent unconditional #else if I didn't move it out of the enclosing #if scope altogether. Gcc-patches: Assuming AG approves, can we commit this without waiting for an upstream libffi release and doing a full merge? Currently GCC HEAD won't build libffi (and hence libjava) without it. 2013-02-21 Dave Korn dave.korn.cyg...@gmail.com * src/closures.c (is_emutramp_enabled [!FFI_MMAP_EXEC_EMUTRAMP_PAX]): Move default definition outside enclosing #if scope. cheers, DaveK -- (*) - Patch: http://sourceware.org/ml/libffi-discuss/2012/msg00269.html - Thread: http://sourceware.org/ml/libffi-discuss/2012/threads.html#00247 Index: src/closures.c === --- src/closures.c (revision 196167) +++ src/closures.c (working copy) @@ -189,8 +189,6 @@ emutramp_enabled_check (void) #define is_emutramp_enabled() (emutramp_enabled = 0 ? emutramp_enabled \ : (emutramp_enabled = emutramp_enabled_check ())) -#else -#define is_emutramp_enabled() 0 #endif /* FFI_MMAP_EXEC_EMUTRAMP_PAX */ #elif defined (__CYGWIN__) || defined(__INTERIX) @@ -202,6 +200,10 @@ emutramp_enabled_check (void) #endif /* !defined(X86_WIN32) !defined(X86_WIN64) */ +#ifndef FFI_MMAP_EXEC_EMUTRAMP_PAX +#define is_emutramp_enabled() 0 +#endif /* FFI_MMAP_EXEC_EMUTRAMP_PAX */ + /* Declare all functions defined in dlmalloc.c as static. */ static void *dlmalloc(size_t); static void dlfree(void*);
Re: GCC 4.7.1 Release Candidate available from gcc.gnu.org
On 06/06/2012 11:14, Richard Guenther wrote: The first release candidate for GCC 4.7.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.1-RC-20120606 and shortly its mirrors. It has been generated from SVN revision 188257. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.7.1 at the end of next week. Heads-up: bootstrap failed on i686-pc-cygwin with missing symbol at make install phase. PR to follow once I've had time to analyze it. cheers, DaveK
Re: Option -pthread in test suite with cross compilers
On 03/06/2012 04:43, Hans-Peter Nilsson wrote: On Fri, 18 May 2012, Ralf Corsepius wrote: On 05/18/2012 09:24 AM, Sebastian Huber wrote: Hi, if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11 target, then I get several unexpected errors due to: gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option '-pthread' gcc/testsuite/g++/g++.log:g++: error: unrecognized command line option '-pthread' The -pthread option is not necessary in RTEMS for the pthread API. I don't think that a special case in the test suite is desirable, thus we should add a dummy -pthread option to the RTEMS target configurations. Is this possible? In which file do I have to look for this? I am not sure, but AFAICT, -pthread is Linux-specific. No, it's the canonical multi-os option to enable pthreads, as generic as it gets. According to the manual(*), it's a machine-dependent option for RS6000 and Solaris 2 only! cheers, DaveK -- (*) - http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Option-Summary.html#Option-Summary
Re: Problems building 4.8 snapshot with CygWin
On 14/04/2012 14:58, Kai Tietz wrote: 2012/4/14 Nicolai Josuttis: The first problem was that build/gcc/gengtype-lex.c was created with DOS-Newlines (CR-LF), which makes the following compiling fail: make[2]: Entering directory `/cygdrive/p/gcc480snap-install/build/gcc' gcc -c-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -Wold-style-definition -fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc-4.8-20120401/gcc -I../../src/gcc-4.8-20120401/gcc/build -I../../src/gcc-4.8-20120401/gcc/../include -I../../src/gcc-4.8-20120401/gcc/../libcpp/include -I/cygdrive/p/gcc480snap-install/build/./gmp -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/gmp -I/cygdrive/p/gcc480snap-install/build/./mpfr -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpfr -I/cygdrive/p/gcc480snap-install/src/gcc-4.8-20120401/mpc/src -I../../src/gcc-4.8-20120401/gcc/../libdecnumber -I../../src/gcc-4.8-20120401/gcc/../libdecnumber/bid -I../libdecnumber \ -o build/gengtype-lex.o gengtype-lex.c After SED-ing CR-LF to LF in that file the compilation continues. About this SED issue I am not sure if this is for real a gcc bug. When this happens, it's usually a result of using a Windows GUI program to unpack the tarball rather than the command-line tar program. WinZIP in particular has a helpful option setting somewhere in the prefs that automatically converts LF-ending files to CR-LF on unpack, IIRC. Use tar -xvfj gcc-4.8-20120401.tar.bz2 instead. cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 22:36, Gabriel Dos Reis wrote: On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote: On 12/04/2012 16:47, Gabriel Dos Reis wrote: I keep talking about useful *warnings*, you keep talking about *numbers*. No you don't. You said: People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. That is talking about numbers. And you were complaining about your comments being taken out of context? Yes, I am, because that statement of your above _was_ the context for the whole rest of the discussion. You were interrupting in between me saying The situation is X and my next sentence where I continued Because of Y. *You* were the one who said that the numbers were a problem because people would expect some kind of monotonic increase in warnings related to the numbers, I was the one who pointed out that the suggestion originally offered exactly matched that situation. Seriously, if you think something like this: Your argument makes no sense. Do you think that assertion makes sens when no evidence is provided to support it? You said that there was a problem because people will expect numbered -W options to be ordinal. ... is anything other than a pedantic interruption in the middle of a coherent argument, you have a communication problem. The basic unit of meaning in English is the paragraph, you can't take part of it alone and expect it to make sense out of context, but if you're going to accuse me of doing the same, well, here's your entire original paragraph: People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. Geodelization is great for machines, hardly so as human interface. There was only one extra sentence in it in the first place, and that other sentence doesn't relate to the first sentence in any way, so I did *not* take your idea out of any kind of context that could in any way have contributed to its coherency. So let's get this silly subthread back on track; here's the summary of where we're at, with all the sidetracks taken out: -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra I like this suggestion a lot. People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. My response to that is that is not a set of confusion, because there is indeed an ordering to the numbers, with zero being less warnings and 3 being most warnings, and therefore it is not a source of confusion but actually a source of correct knowledge about what the situation actually would be, and therefore that using -Wnumber in that way would be a good idea. Now, I admit that I have assumed you meant source of confusion rather than set of confusion, since the latter phrase means nothing in English, so if that's where our misunderstanding has arisen, and you meant something other, then please speak up now and make it clear what you actually meant to convey. cheers, DaveK
Re: RFC: -Wall by default
On 13/04/2012 22:45, Oleg Smolsky wrote: On 2012-04-11 01:50, Vincent Lefevre wrote: On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewarde...@adacore.com wrote: On 4/9/2012 1:36 PM, Jonathan Wakely wrote: Maybe -Wstandard isn't the best name though, as standard usually means something quite specific for compilers, and the warning switch wouldn't have anything to do with standards conformance. -Wdefault might be better except if people want warnings about defaults in C++11 (which can mean lot of things). How about a warning level? -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra This is exactly what Microsoft C++ compiler does and what their Visual Studio IDE exposes in the UI. So, there is a reasonable precedent. Exactly. Would anyone really think it would be a good idea to just not have the -Onumber levels and expect every end user to mix-and-match from a huge set of somewhat unknown-and-unpredictable-just-from-the-names long and confusingly named individual optimisation suboptions? I think -W levels is a new feature that we can easily retrofit on top of the existing structure without having to break or change anything that already works, and that would be equally as user-friendly and pragmatic as having -O levels has already shown itself to be. cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 16:35, Robert Dewar wrote: On 4/12/2012 10:48 AM, Andrew Haley wrote: Ultimately, it's a matter of taste and experience. I'm going to find it hard to write for people who don't know the relative precedence of and | . There are probably some programmers who completely know ALL the operator precedence rules in C. There are probably some subset of those who feel free to write code that takes full advantage of these rules. I would hate to read code written by such people :-) I think it's worth suggesting, in the context of this discussion, that one of the main purposes for which warnings exist in the first place is *didactic*: they are very much intended to help teach the inexperienced about the points of the language that they need to get straight in their heads, and that their code /suggests/ that they haven't done so yet. For that reason, I think that it's OK to have false-positive or slightly over-sensitive warnings; certainly you don't want the noise to drown out the signal, but unless they actually really do flood it out then they're not necessarily a terribly bad thing in their own right. cheers, DaveK
Re: Merging gdc (GNU D Compiler) into gcc
On 11/04/2012 15:12, Iain Buclaw wrote: This has been rather long wait from my side of the pond (moving has taken away quite some time from my side). But I'll be in a position to begin discussion on arrangements this weekend for patches to be submitted for GCC 4.8. I would be grateful if we could start and maintain discussions on making this happen, and I hope some sort of agreement could be reached by the end of the month. Well, we're just out of release freeze and back in stage 1, so there should be plenty of time and not too much problem even if it does kick up some issues that need to be dealt with after the fact. What state are your patches in? cheers, DaveK
Re: FW: is syslimits.h likely to change?
On 12/04/2012 16:38, Mark Galeck (CW) wrote: Thank you Ian, hopefully I will be compatible then for a long time, as Larry Wall would say at least until the heat death of the Universe. I can't ignore it :) My build system cannot handle include_next - it cannot handle the situation where you are finding a header file in one -I directory, and later when you are trying to find it again, you ignore that directory and find it in a subsequent -I directory. The system is extremely fast, like a sports car than will only go on asphalt (standard C and a GCC-like compiler). I'm curious why your build system even needs to handle it? The GCC version of syslimits.h is a private thing, that GCC uses just for its own purposes to adjust or override some of the definitions in the system's native syslimits.h; if you aren't using GCC, then it shouldn't matter, and if you are, then it should be automatic and transparent. And if you're generating dependencies, and using GCC as a compiler, then you should also use gcc -M to generate the dependencies, since it'll get them canonically right, rather than any sort of external makedepends utility. So, why does your build system care about it? cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 07:55, Jakub Jelinek wrote: On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote: The standard says they need not ignore them. I was thinking more about iterating over the contents. What in the current code is an indirect function call inside of a loop becomes mostly be inline functions in a C++ iterator style. The loop is now fully graspable by the optimizer. That comes with its cost though, as we have hundreds of hashtables for various kinds of types, you'd get hundreds of different instantiations of the hash table code. hashtab.c is significantly more I-cache friendly than that. Hmm, is that necessarily the case? GCC is big and I-caches are small; it could well be the case that hashtab.c gets evicted very regularly from the cache, and is only usually constant in it during the course of one individual loop. It wouldn't be any more expensive to map in any one hashtab C++ specialisation vs. another, and they'd all individually be of the same scale as the C hashtab.o code, so unless we have many nested loops that use one kind of hashtab in the outer loop and a different one in the inner loop, we could still end up pretty much where we started from in terms of I-cache usage. I expect profiling would immediately show up whether the two approaches made any significant difference or not, probably very visibly, but I wouldn't dismiss doing the experiment out-of-hand. If the inlining improvements exceed the extra cost of paging, switching to C++ would be justified. cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 22:13, Eric Botcazou wrote: So, you only know it's 2 tokens once you know all of tree.def? I'm aware that this is just some arbitrary example, but I believe this actually strengthens the concern I had. Well, if you don't know of FIELD_DECL, you won't go very far, really. But still, wouldn't it be nice and enhance clarity to be able to use a different character/token between GET and FIELD_DECL than between FIELD and DECL? (Anyway, I still think we should start by just redefining GET_FIELD_DECL et. al. as C++ inline functions - or macros that invoke C++ inline functions, or whatever else that works better for whatever reason, regardless of the implementation details - and let the existing code continue to use them in exactly the same way as before.) cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 13:57, Torvald Riegel wrote: Please don't dismiss this so easily. Of course this is just an example and nothing major, but I believe many people will use tab completion on the shell, for example, and code completion is really similar. On the shell, or with paths names, you start with typing something, then can navigate from this context you provided. That just works better when you say context-function instead of function(context). Say, didn't someone submit a patch at some point to provide a completion-mode for GCC invoked from the command-line? And didn't we (the list) suggest that that would make a lot of sense when combined with the incremental/gccserver branch? Did anything ever happen about that? cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 14:21, Bernd Schmidt wrote: On 04/11/2012 02:57 PM, Torvald Riegel wrote: However, the concern you raised is only one part of the problem. The other is that, put in a simplified way, GCC is competing with LLVM about new and/or non-fulltime-compiler developers. For me, it looks like LLVM is more appealing to them, and I believe part of the reason for that is the codebase. There seem to be other opinions as well, some voiced in this thread, which just supports my argument that you can't do it right for everyone. Part of the reason LLVM is appealing may just be advertising, which we don't do at all, perhaps due to the deep-seated inferiority complex we have about gcc. Inferiority complex? I think this thread suggests (and perhaps the -Wall thread too) that we're more in danger of complacently resting on our laurels. We have huge inertia, but just because we've always been the big name in embedded toolkits doesn't mean we always will be. cheers, DaveK
Re: Switching to C++ by default in 4.8
On 11/04/2012 20:30, Tobias Burnus wrote: In any case, the gfortran front end cannot really afford to loose developers, given that it is a hobbyist* project and given that attracting new developers is difficult. Tobias * In terms of the development; I assume that those who use it for embedded systems or on the top500 supercomputers, at aircraft manufactures, weather services or for academic research get paid. ;-) ;-) Maybe you could work together to twist some arms in management? cheers, DaveK
Re: RFC: -Wall by default
On 11/04/2012 09:50, Vincent Lefevre wrote: On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote: On 4/9/2012 1:36 PM, Jonathan Wakely wrote: Maybe -Wstandard isn't the best name though, as standard usually means something quite specific for compilers, and the warning switch wouldn't have anything to do with standards conformance. -Wdefault might be better except if people want warnings about defaults in C++11 (which can mean lot of things). How about a warning level? -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra I like this suggestion a lot. cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 15:43, Gabriel Dos Reis wrote: On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar de...@adacore.com wrote: On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote: -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra I like this suggestion a lot. Me too! I also like short switches, but gcc mostly favors long hard-to-type not-necessarily-easy-to-remember switch names. People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. What's the problem? The greater the number, the more warnings you get. Simple. Geodelization is great for machines, hardly so as human interface. I don't think the incompleteness theorem is remotely relevant here. cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 15:55, Gabriel Dos Reis wrote: On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 12/04/2012 15:43, Gabriel Dos Reis wrote: People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. What's the problem? The greater the number, the more warnings you get. Simple. Not necessarily. Your argument makes no sense. You said that there was a problem because people will expect numbered -W options to be ordinal. But they *are* ordinal. So people's expectations will be correct. You haven't said anything about where the problem is yet, you've just asserted that there will be one without demonstration or evidence, so again I ask: What's the problem? It works just fine for -O, users understand and are happy with that, why shouldn't it work just as well for -W? cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 16:06, Gabriel Dos Reis wrote: On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 12/04/2012 15:55, Gabriel Dos Reis wrote: On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn dave.korn.cyg...@gmail.com wrote: On 12/04/2012 15:43, Gabriel Dos Reis wrote: People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. What's the problem? The greater the number, the more warnings you get. Simple. Not necessarily. Your argument makes no sense. Do you think that assertion makes sens when no evidence is provided to support it? My assertion was backed up by the sentences immediately after it, you can't just take it out of context and expect it to stand by yourself. Here's the evidence coming up right now: You said that there was a problem because people will expect numbered -W options to be ordinal. What is nonsensical there? Well stop interrupting and let me finish! The very next sentence points out what is nonsensical about your statement: But they *are* ordinal. Now? What is the order? Zero, then one, then two, then three. Are we having a language difficulty here? You can't really be asking me what the ordinal sequence of the integers is. So people's expectations will be correct. You haven't said anything about where the problem is yet, you've just asserted that there will be one without demonstration or evidence, so again I ask: What's the problem? You said the greater the number the more warnings you get, but you did not show that would happen, so you have not shown that would necessarily happen. What is nonsensical there? You appear to have forgotten what we're talking about, so let me remind you: -W0: no warnings (equivalent to -w) -W1: default -W2: equivalent to the current -Wall -W3: equivalent to the current -Wall -Wextra There will be more warnings the greater the number because that is how it was defined to work. The default will be the suggestion we've been discussing so far, i.e. effectively -Wall with a few of the less useful warnings removed. It works just fine for -O, Exactly what happens with -O? -On does not necessarily generate faster or better code when n is higher. Exactly, just like how it would be with warnings. -On when n is higher uses more optimisations, some of which may be problematic - we're warned that -O3 may be unstable, and similarly -W3 may turn on warnings that are more of a hinderance than a help. cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 17:03, Gabriel Dos Reis wrote: There is little ambiguity left by -Wreally-all-of-them-damn-it :-) Actually, no, as anyone could tell you who before they discovered version control used to have lots of files lying around called foo.final.c, foo.final.reallyfinal.c, foo.final.updated.reallyfinalthistime.c, and so on; in other words, I think that after a few years have passed, we would find that we've been persuaded to add -Wreally-really-all-of-them-damn-it, -Wreally-really-all-no-actually-all-including-everything, and -Wreally-really-all-of-them-damn-it-no-i-really-did-mean-all-of-them-even-including-the-really-unexpected-ones. There's nothing more ambiguous than saying that something is final in a world where perfection is never achieved. That's why software has monotonically increasing version numbers, instead of just one that means this is done now. cheers, DaveK
Re: RFC: -Wall by default
On 12/04/2012 16:47, Gabriel Dos Reis wrote: I keep talking about useful *warnings*, you keep talking about *numbers*. No you don't. You said: People easily associates some ordering to numbers (usually the greater the better or in this case the worse) which creates another set of confusion. That is talking about numbers. I'm not going to bother reading the rest of your email, you're just being argumentative and misunderstanding on purpose. DaveK.
Re: Switching to C++ by default in 4.8
On 10/04/2012 17:24, Michael Matz wrote: Hi, On Tue, 10 Apr 2012, Xinliang David Li wrote: exp-as_component_ref().get_field() .. Actually it's not questionable. The above stuff is _horrible_. Specifics please. It is _horrible_ because you are more used to the existing way and the new style does not match your taste or they are very hard to understand and use? Your style (I wouldn't call it The New Style) is visually distracting, and therefore harder to understand and use, longer to write and full of syntactic noise without any whitespace. Quite frankly, how anyone could ever say that exp-as_component_ref().get_field() is easier to read/write/use than GET_FIELD_DECL (exp) (say when we #define GET_FIELD_DECL(x) TREE_OPERAND(x,1)), with or without all-caps, is completely beyond me. I pretty much hope that we never see the ugliness of the first way in GCCs code base. Even in C++ it's possible to write non-spaghetti code. So isn't #define GET_FIELD_DECL(exp) ((exp)-as_component_ref().get_field()) the simple solution to that one? cheers, DaveK
Re: Switching to C++ by default in 4.8
On 10/04/2012 17:41, Paweł Sikora wrote: On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote: On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: Class hierarchy is one such feature that is useful. Assuming we have two hierarchies for gcc: one for values rooted at ValExp, and one for gimple stmts rooted at GimpInst. 1) For IR browsing, *) all the macro accessors can be eliminated -- a big plus for debugging; Not that clear, if all the macros are replaced by tons of inline functions, the debugging experience can be actually significantly worse. debugabilty can be improved with set of gdb python pretty printers which could present gcc's structures in human readable form (instead of union mix). Would that be much different from call debug_tree(x) which we already have? cheers, DaveK
Re: RFC: -Wall by default
On 07/04/2012 23:58, Gabriel Dos Reis wrote: On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn wrote: -Wunused-function -Wunused-label -Wunused-value -Wunused-variable IMHO we should move the -Wunused ones into -Wextra if we're going to turn on -Wall by default. The rest seem pretty reasonable defaults to me. Even if we do not turn on -Wall by default, do you think we should have -Wunused in -Wall? I think they're of limited use, bearing in mind typical C usage patterns, but unless we were upheaving everything anyway, I can't see much reason to change the status quo. cheers, DaveK
Re: RFC: -Wall by default
On 05/04/2012 10:46, Gabriel Dos Reis wrote: On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther richard.guent...@gmail.com wrote: Btw, it would be more reasonable to enable a subset of warnings that we enable at -Wall by default. Which ones for example? Here is a (partial) list: Your list seems a bit short, here's what today's trunk build says for -Wall: -Waddress -Warray-bounds (only with `-O2') -Wc++11-compat -Wchar-subscripts -Wenum-compare (in C/Objc; this is on by default in C++) -Wimplicit-int (C and Objective-C only) -Wimplicit-function-declaration (C and Objective-C only) -Wcomment -Wformat -Wmain (only for C/ObjC and unless `-ffreestanding') -Wmaybe-uninitialized -Wmissing-braces -Wnonnull -Wparentheses -Wpointer-sign -Wreorder -Wreturn-type -Wsequence-point -Wsign-compare (only in C++) -Wstrict-aliasing -Wstrict-overflow=1 -Wswitch -Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunused-function -Wunused-label -Wunused-value -Wunused-variable -Wvolatile-register-var IMHO we should move the -Wunused ones into -Wextra if we're going to turn on -Wall by default. The rest seem pretty reasonable defaults to me. cheers, DaveK
Re: Maybe it's a virus
On 10/03/2012 09:30, niXman wrote: When extracting ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.6.3/gcc-4.6.3.tar.bz2 http://clip2net.com/clip/m0/1331371739-clip-8kb.png Don't worry, it's not a virus. It's a recursive zip file: http://research.swtch.com/zip It's data for a testcase, there to make sure the go library routines that handle archives can deal with a corrupt zip file without crashing. The reason that your antivirus gets in a panic about it is that if you email someone a recursive zip file as an attachment, it'll often crash their antivirus when it tries to scan inside the zip file, and then other attachments on the same email will go un-scanned, potentially allowing something dangerous to get through; this has been a trick used by viruses in the past to slip past mail scanners. In the context of the GCC testsuite however, it's not any kind of threat or problem; just treat it as a false positive. cheers, DaveK
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
On 22/02/2012 16:25, Pascal Obry wrote: Dave, Pascal, ping? Sorry for the delay, these message has fallen into the crack! No problem, I had plenty to be getting on with in the meantime :) Anyway, with these explanations I'm ok with the patch. Thanks. Committed revision 184558. cheers, DaveK
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
On 09/01/2012 11:56, Eric Botcazou wrote: Sorry for the delay guys, I got rather busy over the holidays. I see we're now discussing a patch for next stage 1. No, not necessarily, the patch is specific to Ada on Windows so the risk is quite low. It does however solve the problem of wanting the DLL to be in the /bin directory, while still needing something to stand in its place in the /lib directory so that the linker can find it without the compiler having to put -L$prefix/bin in the specs. This indeed sounds compelling enough. It's also used on Cygwin and MinGW to address library versioning: the actual DLL has a numbered suffix to indicate version, but the import library is unnumbered, so you can just say -lblah as usual and automatically link against whatever the installed version of the DLL is without having to know the version suffix and specify it in the -l option. Ada doesn't need that, as it happens, because it always generates the specfile to explicitly include the version number of libgnat/libgnarl in the -l option, and doesn't try to keep the shared library compatible across point releases of the compiler, but it's how all the other runtimes work on Windows; they all put an import library in /lib and the DLL itself into /bin. Ada should work the same way, because otherwise you either need to point your PATH into gcc's private dir at runtime, or point your linker into /bin at linktime, neither of which are entirely neat solutions. If all the other runtimes do it, I think we should do it too. Pacal, what do you think? Pascal, ping? cheers, DaveK
Re: [patch ada]: Fix PR/50942
On 09/02/2012 18:55, Kai Tietz wrote: Hmm, I interpret 'ifeq ($(strip $(filter-out alpha64 ia64 dec hp vms% openvms% alphavms%,$(host))),)' as anthing not mentioned here. If, after removing alpha64 ia64 dec hp vms% openvms% alphavms% (and stray whitespace) from the host, what remains is equal to nothing - If host consists only of things in alpha64 ia64 dec hp vms% openvms% alphavms%. It's a slightly confusing construct I agree. Watch out for the difference between filter vs. filter-out and ifeq vs. ifneq, and note that that final comma indicates there's an empty string as arg2 of the if condition. cheers, DaveK
Re: weird optimization in sin+cos, x86 backend
On 05/02/2012 19:01, Vincent Lefevre wrote: On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote: But it is indistinguishable from 10^22+pi. So both -0.8522008497671888 and 0.8522008497671888 are correct results, or anything inbetween. No, 10^22 and 10^22+pi are different numbers. Only one of which can be represented in floating point. So, the gist of the argument is that FP numbers do not represent ranges; they are a precise but sparse representation of the number line. It's still not a lot of use doing trig up at the top end of the FP range where 1 ulp 2pi. The odds of the value that you wanted to represent actually being representable are tiny, and hence so are the odds of getting anything like the result you were hoping for. But, at least identities should work. cheers, DaveK
Re: weird optimization in sin+cos, x86 backend
On 04/02/2012 10:20, James Courtier-Dutton wrote:
#include stdio.h
#include math.h
int main (void)
{
double x, c, s;
volatile double v;
x = 1.0e22;
s = sin (x);
printf (sin(%.17g) = %.17g\n, x, s);
v = x;
x = v;
c = cos (x);
s = sin (x);
printf (sin(%.17g) = %.17g\n, x, s);
return c == 0;
}
If you convert all the doubles into long doubles.
You get:
... invalid code unless you remembered to add 'L' before the 'g' format
specifier as well. Did you? (Just checking.)
cheers,
DaveK
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 16:46, Andreas Krebbel wrote: Divide_1::probe_1() - __divdi3 |SIGFPE V catch_fpe - _Jv_Throw After doing the instruction parsing in order to figure out whether it's actually the INT_MIN/-1 case or not an exception is thrown. During _Unwind_RaiseException the handler is found in probe_1 and in order to re-find it in phase2 the CFA! is recorded in the private_2 field of the exception. Starting with this IRA patch: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html __divdi3 does *not* need a stack frame at all. So the CFAs of __divdi3 and probe_1 are the same! This triggers the assertion in _Unwind_RaiseException_Phase2 which assumes that it is about to pass the frame with the handler without actually finding one. Wouldn't it work to just let the unwind loop continue running if the next frame's CFA is the same as the current one's? cheers, DaveK
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 16:58, Dave Korn wrote: On 27/01/2012 16:46, Andreas Krebbel wrote: So the CFAs of __divdi3 and probe_1 are the same! This triggers the assertion in _Unwind_RaiseException_Phase2 which assumes that it is about to pass the frame with the handler without actually finding one. Wouldn't it work to just let the unwind loop continue running if the next frame's CFA is the same as the current one's? (Answering myself) No, it won't be enough; it would solve that particular inlining case but not if there was a stack of recursive calls through one or more intermediate functions. I think adopting the GDB convention of IP+CFA to identify the context is probably necessary after all. cheers, DaveK
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 17:01, Andrew Haley wrote: On 01/27/2012 04:46 PM, Andreas Krebbel wrote: Starting with this IRA patch: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html __divdi3 does *not* need a stack frame at all. So the CFAs of __divdi3 and probe_1 are the same! I'm confused. But __divdi3 should have been compiled with enough unwinder data that it can be found; it should not matter whether __divdi3 has a stack frame or not. So why doesn't __divdi3 have a CFA of its own? Unless I've misunderstood, it's because the CFA *is* the stack frame (base?) pointer. cheers, DaveK
Re: Divide_1 testsuite fail due to a problem in the unwinding code
On 27/01/2012 17:16, Andrew Haley wrote: On 01/27/2012 05:14 PM, Dave Korn wrote: On 27/01/2012 17:01, Andrew Haley wrote: On 01/27/2012 04:46 PM, Andreas Krebbel wrote: Starting with this IRA patch: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html __divdi3 does *not* need a stack frame at all. So the CFAs of __divdi3 and probe_1 are the same! I'm confused. But __divdi3 should have been compiled with enough unwinder data that it can be found; it should not matter whether __divdi3 has a stack frame or not. So why doesn't __divdi3 have a CFA of its own? Unless I've misunderstood, it's because the CFA *is* the stack frame (base?) pointer. Ah, it's not that it has no stack frame, it's that it has no stack adjustment at all, not even a push? Well the return address might get pushed but if the CFA is the stack frame base rather than current stack pointer, that won't change. So I expect this could happen with inline and nested functions too. (Or do nested functions set up a stack frame? I don't know.) cheers, DaveK
Re: [patch] Fix mismatched #pragma GCC visibility
On 25/01/2012 03:27, Rafael Ávila de Espíndola wrote:
Sorry, one more case that gcc accepts where it is not clear what the
result should be:
-
#pragma GCC visibility push(protected)
int x;
class __attribute__((visibility(hidden))) foo {
static int a;
#pragma GCC visibility pop
static int b;
};
int y;
int foo::a;
int foo::b;
-
Should this be reject (as happens with namespaces)? If not what is the
expected result? Currently we get
x - protected
y - default
a - hidden
b - hidden
According to the manual:
In C++, `#pragma GCC visibility' affects only namespace-scope
declarations. Class members and template specializations are not
affected; if you want to override the visibility for a particular
member or instantiation, you must use an attribute.
Looks like it's working to me.
cheers,
DaveK
Re: Dealing with compilers that pretend to be GCC
On 20/01/2012 11:19, Peter Rosin wrote: Dave Korn skrev 2012-01-20 01:15: *snip* That could be tricky because I guess you won't be able to use libtool at configure time. *snip* It's possible to use libtool at configure time, but you need to invoke LT_OUTPUT before you do so. Or is there a reason for that not to work in this case? Not as far as I know, I just wasn't aware that you could generate the output script early. cheers, DaveK
Re: Dealing with compilers that pretend to be GCC
On 20/01/2012 23:28, Jonathan Wakely wrote: 2012/1/20 Ludovic Courtès: Yeah, but it’s a shame that those compilers define __GNUC__ without supporting 100% of the GNU C extensions. With this approach, you would also need to add !defined for Clang, PGI, and probably others. May I politely suggest that this is the wrong place to complain about other compilers pretending to be GCC :) If GCC added a __REALLY_GNUC__ macro the other compilers would define it, for exactly the same reasons they define __GNUC__ I do agree with the proposition that if you pretend to be GCC, but don't do it completely and well enough, that's a bug that should be fixed in the compiler pretending to be GCC. OTOH the entire point of autotools is that any toolchain (even GCC itself) sometimes has bugs or unimplemented features, and you just can't argue with the principle that the definitive test is always going to be try and use the feature and verify if it worked or not. Therefore autoconf tests should not just test __GNUC__, unless the only thing they're trying to be a test for is whether __GUNC__ is defined or not. cheers, DaveK
Re: Dealing with compilers that pretend to be GCC
On 19/01/2012 16:51, Ludovic Courtès wrote: Right. But how would you write feature tests that would check (1) whether the GNU C language is supported, Try and compile a conftest that uses it. If you wanted a possibly over-engineered solution, write one conftest for each feature of GNU C that you might want to use; otherwise maybe just write one conftest that uses as many different features as you can think of. and (2) whether GCC plug-ins are supported? Write a conftest that actually compiles a minimal basic gcc plugin, attempts to invoke the compiler with it, and looks for it to output Hello world or whatever. That could be tricky because I guess you won't be able to use libtool at configure time. Maybe you could just try invoking the compiler with the right options to load the lto-plugin, check that that works, then invoke it with a -plugin option pointing to a non-existent file name and make sure that that fails, just to be sure that the compiler is actually using the option flag and not just ignoring it. cheers, DaveK
Re: trouble emilinating redundant compares
On 17/01/2012 21:16, Paul S wrote: For example the i386 seems to use predicates and constraints of the form *_operand and m/r/i for the reload versions of these instructions - and I haven't been able to find definitions of these or a mention in gcc_internals.pdf of any special meaning assigned to the notation. See http://gcc.gnu.org/onlinedocs/gccint/Substitutions.html, and take a look for the define_[code/mode]_[attr/iterator] definitions around line ~650ish of i386.md cheers, DaveK
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
On 17/12/2011 11:07, Eric Botcazou wrote: I am happily using this patch and await this to be committed. Only after the import library issue is addressed. What do the other libraries bundled with GCC do here? Sorry for the delay guys, I got rather busy over the holidays. I see we're now discussing a patch for next stage 1. Well, to the point: I thinko'd slightly when I said that import libraries are preferred; it's the platform convention, and it's the way the MS toolchain works because it can't link directly against DLLs, but it's not (as I mistakenly assumed at the time, although did not explicitly state) any more correct or valid. It does however solve the problem of wanting the DLL to be in the /bin directory, while still needing something to stand in its place in the /lib directory so that the linker can find it without the compiler having to put -L$prefix/bin in the specs. It's also used on Cygwin and MinGW to address library versioning: the actual DLL has a numbered suffix to indicate version, but the import library is unnumbered, so you can just say -lblah as usual and automatically link against whatever the installed version of the DLL is without having to know the version suffix and specify it in the -l option. Ada doesn't need that, as it happens, because it always generates the specfile to explicitly include the version number of libgnat/libgnarl in the -l option, and doesn't try to keep the shared library compatible across point releases of the compiler, but it's how all the other runtimes work on Windows; they all put an import library in /lib and the DLL itself into /bin. Ada should work the same way, because otherwise you either need to point your PATH into gcc's private dir at runtime, or point your linker into /bin at linktime, neither of which are entirely neat solutions. cheers, DaveK
Re: [patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
On 17/12/2011 10:06, Christian Joensson wrote: I can add that I also, manually, copy the lto-plugin/.libs/cyglto_plugin-0.dll into $bindir too. Why? It deliberately installs into libexecsubdir rather than bindir because it's only ever invoked by the gcc driver, which passes the full explicit path in the -plugin option on the command-line for ld to pass to dlopen(); it shouldn't need to be found on $PATH at all if everything's working as intended. cheers, DaveK
Re: new mailing list language-experts
On 03/01/2012 17:43, Bruno Haible wrote: https://lists.gnu.org/mailman/listinfo/language-experts Or https://lists.nongnu.org/mailman/listinfo/language-experts if you want to avoid the certificate mismatch security warning :) cheers, DaveK
Re: [patch testsuite g++.dg]: Reflect ABI change for windows native targets about bitfield layout in structures
On 16/12/2011 09:01, Kai Tietz wrote:
2011/12/15 Dave Korn:
{ dg-options -mno-align-double { target i?86-*-cygwin* i?86-*-mingw* } }
{ dg-additional-options -mno-ms-bitfields { target i?86-*-mingw* } }
... so that MinGW gets both and Cygwin only the one it wants? (Actually the
first one could just as well be changed to dg-additional-options at the same
time, couldn't it?)
Well, interesting. I think it should be the additional variant for
cygwin/mingw, as otherwise -O2 gets clobbered for it, isn't it?
Yes, that's what I was concerned with.
So I modified patch as attached.
Thanks for that. I recommend this patch for approval.
cheers,
DaveK
Re: [patch testsuite g++.dg]: Reflect ABI change for windows native targets about bitfield layout in structures
On 15/12/2011 10:33, Kai Tietz wrote:
-// { dg-options -mno-align-double { target i?86-*-cygwin* i?86-*-mingw* } }
+// As for mingw target the the ms-bitfield switch is activated by default,
+// make sure for this test that it is disabled.
+// { dg-options -mno-align-double -mno-ms-bitfields { target
i?86-*-cygwin* i
?86-*-mingw* } }
We don't use ms-bitfields on Cygwin, so I guess it wouldn't be expected to
do any harm anyway, but rather than setting the same options for both wouldn't
it be possible to do:
{ dg-options -mno-align-double { target i?86-*-cygwin* i?86-*-mingw* } }
{ dg-additional-options -mno-ms-bitfields { target i?86-*-mingw* } }
... so that MinGW gets both and Cygwin only the one it wants? (Actually the
first one could just as well be changed to dg-additional-options at the same
time, couldn't it?)
cheers,
DaveK
Re: [patch testsuite g++.old-deja]: Fix some testcases for mingw targets
On 15/12/2011 17:44, Mike Stump wrote: On Dec 15, 2011, at 1:43 AM, Kai Tietz wrote: This patch takes care that we are using for operator new/delete replacement test static version on mingw-targets. As the shared (DLL) version isn't able to have operator overload within DLL itself, as a DLL is finally-linked for PE-COFF. Ok for apply? Not sure who would review this if I don't, so, Ok. That said, if a shared library C++ type person wants to chime in... I get the feeling this is unfortunate, and it might have been nice to manage this in some other way, but, I just want to step back and let others think about it. Well, it's a consequence of how you can't leave undefined references in Windows DLLs at link-time for the loader to just fill in with the first definition it comes across at run-time (as you can on ELF). We have to jump through hoops to get operator new/delete replacement working on Cygwin, and were lucky in that the cygwin1.dll is linked against absolutely everything, so we had somewhere to hang our redirection hooks. Without someone adding some similar amount of infrastructure to MinGW, the only time function replacement can work is for a statically-linked executable, when all definitions are visible in one single link. * g++.old-deja/g++.brendan/new3.C: Adjust test for mingw targets to use static-version. s/static-version/static linking/ +// Avoid use of none-overridable new/delete operators in shared s/none-overridable/non-overridable/g s/in shared/in shared link/g Patch looks perfectly sensible to me, but I can't approve. cheers, DaveK
Re: GC warnings and libjava/boehm.cc thread warnings on current gcc with java on cygwin
On 12/12/2011 20:20, Christian Joensson wrote: Exception in thread main java.lang.NoClassDefFoundError: loaded class gnu.classpath.tools.jar.messages was in fact named gnu.classpath.tools.jar.Messages I think I discovered recently that you absolutely have to have obcaseinsensitive=0 to build java these days. The other stuff will take me longer to get to looking at. cheers, DaveK
[patch] Fix cygwin ada install [was Re: Yet another issue with gcc current trunk with ada on cygwin]
Hi again guys,
After the previous patch, there's still another bug remaining in the Ada
makefile, relating to how it builds and installs the gnat/gnarl shared
libraries.
Windows doesn't have any concept of an rpath in executables, nor of
LD_LIBRARY_PATH; all required DLLs must be found on the PATH when an exe is
invoked. The Ada shared libraries are currently installed into adaobj/ in the
gcc private dir, which is not (and should not be) on users' PATHs, so the
result is that executables compiled with the -shared binder option don't work.
The attached patch fixes Windows DLLs to be installed into $bindir, and
while it does that it also generates import libraries, which live in the
private adaobj/ directory and serve for linking executables to the DLLs (it's
actually preferred to link against an import library than directly against the
DLL itself). Finally it adjusts the name of the DLLs on Cygwin to match the
cyg*.dll naming scheme used there to avoid clashes with MinGW DLLs.
libada/ChangeLog:
* Makefile.in (bindir): Import from autoconf and pass down to submake.
gcc/ada/ChangeLog:
* gcc-interface/Makefile.in (WIN_SO_PREFIX [windows targets]): New
Windows-specific make variable.
(WIN_SO_INSTALL_DIR [windows targets]): Likewise.
(install-gnatlib): Respect the above during installation when set,
and also install any windows import library that has been built.
(gnatlib-shared-win32): Use WIN_SO_PREFIX to name output DLL and also
build a corresponding import library.
Built, tested, installed on i686-pc-cygwin and x86_64-unknown-linux-gnu, no
regressions anywhere, verified that DLL install locations are corrected on
windows and the .so install locations unchanged on Linux. Ok?
cheers,
DaveK
Index: libada/Makefile.in
===
--- libada/Makefile.in (revision 182075)
+++ libada/Makefile.in (working copy)
@@ -33,6 +33,7 @@ MULTICLEAN = true
SHELL = @SHELL@
srcdir = @srcdir@
libdir = @libdir@
+bindir = @bindir@
build = @build@
target = @target@
prefix = @prefix@
@@ -83,6 +84,7 @@ LIBADA_FLAGS_TO_PASS = \
TRACE=$(TRACE) \
MULTISUBDIR=$(MULTISUBDIR) \
libsubdir=$(libsubdir) \
+bindir=$(bindir) \
objext=$(objext) \
prefix=$(prefix) \
exeext=.exeext.should.not.be.used \
Index: gcc/ada/gcc-interface/Makefile.in
===
--- gcc/ada/gcc-interface/Makefile.in (revision 182075)
+++ gcc/ada/gcc-interface/Makefile.in (working copy)
@@ -1588,16 +1588,19 @@ ifeq ($(strip $(filter-out cygwin% mingw32% pe,$(o
# the Cygwin port has always been a CygMing frankenhybrid and it is
# a long-term project to disentangle them.
ifeq ($(strip $(filter-out cygwin%,$(osys))),)
+WIN_SO_PREFIX=cyg
LIBGNAT_TARGET_PAIRS = \
s-memory.adbs-memory.adb \
g-socthi.adsg-socthi.ads \
g-socthi.adbg-socthi.adb
else
+WIN_SO_PREFIX=lib
LIBGNAT_TARGET_PAIRS = \
s-memory.adbs-memory-mingw.adb \
g-socthi.adsg-socthi-mingw.ads \
g-socthi.adbg-socthi-mingw.adb
endif
+ WIN_SO_INSTALL_DIR = $(bindir)
LIBGNAT_TARGET_PAIRS += \
a-dirval.adba-dirval-mingw.adb \
a-excpol.adba-excpol-abort.adb \
@@ -2448,11 +2451,14 @@ install-gnatlib: ../stamp-gnatlib-$(RTSDIR)
# for shared libraries on some targets, e.g. on HP-UX where the x
# permission is required.
# Also install the .dSYM directories if they exist (these directories
-# contain the debug information for the shared libraries on darwin)
+# contain the debug information for the shared libraries on darwin),
+# and the windows import libraries if they exist.
+ libpfx=$(if $(WIN_SO_PREFIX),$(WIN_SO_PREFIX),lib); \
+ librtlobjdir=$(if $(WIN_SO_INSTALL_DIR),$(WIN_SO_INSTALL_DIR),$(ADA_RTL_OBJ_DIR)); \
for file in gnat gnarl; do \
- if [ -f $(RTSDIR)/lib$${file}$(hyphen)$(LIBRARY_VERSION)$(soext) ]; then \
- $(INSTALL) $(RTSDIR)/lib$${file}$(hyphen)$(LIBRARY_VERSION)$(soext) \
- $(DESTDIR)$(ADA_RTL_OBJ_DIR); \
+ if [ -f $(RTSDIR)/$${libpfx}$${file}$(hyphen)$(LIBRARY_VERSION)$(soext) ]; then \
+ $(INSTALL) $(RTSDIR)/$${libpfx}$${file}$(hyphen)$(LIBRARY_VERSION)$(soext) \
+ $(DESTDIR)$${librtlobjdir}; \
fi; \
if [ -f $(RTSDIR)/lib$${file}$(soext) ]; then \
$(LN_S) lib$${file}$(hyphen)$(LIBRARY_VERSION)$(soext) \
@@ -2462,6 +2468,10 @@ install-gnatlib: ../stamp-gnatlib-$(RTSDIR)
$(CP) -r $(RTSDIR)/lib$${file}$(hyphen)$(LIBRARY_VERSION)$(soext).dSYM \
$(DESTDIR)$(ADA_RTL_OBJ_DIR); \
fi; \
+ if [ -f $(RTSDIR)/lib$${file}$(hyphen)$(LIBRARY_VERSION)$(soext)$(arext) ]; then \
+ $(INSTALL_DATA) $(RTSDIR)/lib$${file}$(hyphen)$(LIBRARY_VERSION)$(soext)$(arext) \
+ $(DESTDIR)$(ADA_RTL_OBJ_DIR); \
+ fi; \
done
# This copy must be done preserving the date on the original
Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
On 07/12/2011 19:14, Christian Joensson wrote:
I am trying to build gcc trunk on cygwin (with the snapshot of
20111207) and get this:
/usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o
In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0,
from /usr/local/src/trunk/gcc/gcc/ada/adaint.c:107:
/usr/include/sys/wait.h: In function 'int __wait_status_to_int(const wait)':
/usr/include/sys/wait.h:77:61: error: declaration of C function 'int
__wait_status_to_int(const wait)' conflicts with
/usr/include/sys/wait.h:75:12: error: previous declaration 'int
__wait_status_to_int(int)' here
make[3]: *** [ada/adaint.o] Error 1
Does this symptom ring a bell for anyone?
Ah, I didn't see it because I'm not using the snapshot (and I haven't been
testing C++ builds recently either).
#ifdef __cplusplus
inline int __wait_status_to_int (int __status)
{ return __status; }
inline int __wait_status_to_int (const union wait __status)
{ return __status.w_status; }
I can see why it happens: when adaint.c #includes sys/wait.h, it's already
one level deep inside extern C { ... } nesting. So those new overloads in
sys/wait.h (snapshot version) can't be name-mangled.
Any lurking standards lawyers out there? Is it valid to #include a C
standard header inside an extern C block? Should the Cygwin header use
extern C++ on those declarations even though they're inside #ifdef
__cplusplus, or should adaint.c not #include things inside extern C?
cheers,
DaveK
Re: Suspicion of regression in uninitialized value detection
On 05/12/2011 21:43, Jeff Law wrote: When the uninitialized initialized to 10 paths meet, the compiler (correctly) pretends the value for the uninitialized path is 10 as well. Wouldn't that be a good point at which to issue an uninitialised-use warning? cheers, DaveK
Re: Is ada's make install parallel-safe?
On 03/12/2011 12:16, Dave Korn wrote: Running make -j8 install in a fresh build of head, I saw loads of the following error messages coming out in the log: cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoau.adb': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoio.adb': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zttest.ads': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zzboio.ads': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/ada.ads': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/directio.ads': File exists [ ... snip ... ] Sure enough, all the files did exist, so I guess it must have been trying to install them twice. Before I try digging deeper, I thought I'd quickly ask: Does anyone else see this? (Is it perhaps something that wouldn't show up on a different host, such as linux, owing to differing filesystem semantics?) This is confirmed and turns out to be the (known and now reopened) PR bootstrap/38388. cheers, DaveK
Is ada's make install parallel-safe?
Hi list, Running make -j8 install in a fresh build of head, I saw loads of the following error messages coming out in the log: cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoau.adb': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoio.adb': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zttest.ads': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zzboio.ads': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/ada.ads': File exists cp: cannot create regular file `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/directio.ads': File exists [ ... snip ... ] Sure enough, all the files did exist, so I guess it must have been trying to install them twice. Before I try digging deeper, I thought I'd quickly ask: Does anyone else see this? (Is it perhaps something that wouldn't show up on a different host, such as linux, owing to differing filesystem semantics?) cheers, DaveK
Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: Specific is undefined (more references follow)
On 23/11/2011 08:43, Eric Botcazou wrote:
On 23/11/2011 07:28, Eric Botcazou wrote:
/usr/local/src/trunk/objdir.withada/./gcc/xgcc
-B/usr/local/src/trunk/objdir.withada/./gcc/
-B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem
/usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include
-c -g -O2-W -Wall -gnatpg -nostdinc g-socthi.adb -o g-socthi.o
g-socthi.adb:615:15: WSASYSNOTREADY is undefined
g-socthi.adb:616:15: WSAVERNOTSUPPORTED is undefined
g-socthi.adb:618:15: WSANOTINITIALISED is undefined
g-socthi.adb:620:15: WSAEDISCON is undefined
g-socthi.adb:627:15: duplication of choice value at line 575
make[6]: *** [g-socthi.o] Error 1
and that is beyond my grasp, there is something odd when cygwin is to
use, I guess, mingw variants of files...
But grep is your friend. See s-oscons-tmplt.c lines 1343 and below.
Try adding defined (__CYGWIN__) to the first line.
Actually, the real problem is that the Cygwin-targeted version of gnat
shouldn't need those definitions in the first place. Cygwin provides a fairly
complete Linux/Posix feature-set, and doing an end-run around it by using the
underlying winsock API isn't usually a good idea, so I think that the better
solution is to switch over to the standard berksock implementation.
The attached patch does that, and it also switches to the standard c-malloc
implementation, as the MinGW version relies on the _msize() API that isn't
provided in Cygwin.
I also had to rejig the sysdep functions a bit, in order to make
__gnat_is_windows_xp() and __gnat_get_stack_bounds() available, else the final
link fails. (I don't know what uses those, but would guess exception
handling; we should switch that over at some point too most likely, but let's
go one step at a time. In the long run we probably ought to switch Cygwin
gnat over to use all the standard implementations and none of the MinGW
versions, but that's a larger and more complicated job, so this patch just
switches those two mentioned, which is the minimum needed to get it building
again.)
gcc/ada/ChangeLog:
* gcc-interface/Makefile.in (WIN_TARG_SUFFIX): New variable, used by
windows targets only to differentiate between MinGW and Cygwin.
(LIBGNAT_TARGET_PAIRS [windows targets]): Correctly detect cygwin,
which no longer has the '32' suffix, and use WIN_TARG_SUFFIX to choose
appropriate implementations of the sockets and memory packages.
* sysdep.c (WIN_SETMODE): New define to choose the correct spelling of
setmode/_setmode for MinGW and Cygwin, respectively.
(__gnat_set_binary_mode [windows targets]): Use the above, and enable
the windows version for Cygwin as well as MinGW.
(__gnat_set_text_mode [windows targets]): Likewise.
(__gnat_ttyname [windows targets]): Provide a Cygwin implementation
in addition to the MinGW version.
(__gnat_is_windows_xp): Make available to Cygwin as well as MinGW.
(__gnat_get_stack_bounds): Likewise.
With this patch it all builds again. Tests running, but the results have to
be better than not even building at all! OK for trunk?
cheers,
DaveK
Index: gcc/ada/gcc-interface/Makefile.in
===
--- gcc/ada/gcc-interface/Makefile.in (revision 181901)
+++ gcc/ada/gcc-interface/Makefile.in (working copy)
@@ -1573,18 +1573,23 @@ ifeq ($(strip $(filter-out avr none powerpc% eabis
indepsw.adbindepsw-gnu.adb
endif
-ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),)
+ifeq ($(strip $(filter-out cygwin% mingw32% pe,$(osys))),)
+ ifeq ($(strip $(filter-out cygwin%,$(osys))),)
+WIN_TARG_SUFFIX=
+ else
+WIN_TARG_SUFFIX=-mingw
+ endif
LIBGNAT_TARGET_PAIRS = \
a-dirval.adba-dirval-mingw.adb \
a-excpol.adba-excpol-abort.adb \
s-gloloc.adbs-gloloc-mingw.adb \
s-inmaop.adbs-inmaop-dummy.adb \
- s-memory.adbs-memory-mingw.adb \
+ s-memory.adbs-memory$(WIN_TARG_SUFFIX).adb \
s-taspri.adss-taspri-mingw.ads \
s-tasinf.adbs-tasinf-mingw.adb \
s-tasinf.adss-tasinf-mingw.ads \
- g-socthi.adsg-socthi-mingw.ads \
- g-socthi.adbg-socthi-mingw.adb \
+ g-socthi.adsg-socthi$(WIN_TARG_SUFFIX).ads \
+ g-socthi.adbg-socthi$(WIN_TARG_SUFFIX).adb \
g-stsifd.adbg-stsifd-sockets.adb \
g-soliop.adsg-soliop-mingw.ads \
$(ATOMICS_TARGET_PAIRS)
Index: gcc/ada/sysdep.c
===
--- gcc/ada/sysdep.c (revision 181901)
+++ gcc/ada/sysdep.c (working copy)
@@ -120,38 +120,44 @@ extern struct tm *localtime_r(const time_t *, stru
*/
-#if defined(WINNT)
+#if defined (WINNT) || defined (__CYGWIN__)
const char __gnat_text_translation_required = 1;
+#ifdef __CYGWIN__
+#define WIN_SETMODE setmode
+#include io.h
+#else
+#define WIN_SETMODE _setmode
+#endif
+
void
__gnat_set_binary_mode (int handle)
{
- _setmode (handle, O_BINARY);
+ WIN_SETMODE (handle,
Re: volatile correctness: combine vs. target.md
On 01/12/2011 21:40, Georg-Johann Lay wrote: It's not unusual because: * It's not unusual to write down SFRs as violatile memory like (*((volatile unsigned int*) 0x1234)) or as a cast to a composite that reflects the SFRs bit(field)s. * It's not unusual that microcontrollers can access specific parts of memory -- in particular I/O -- with special instructions. Great. Now I'm going to be hearing Tom Jones in my head for the rest of the day! :) (ObTopic: Andrew H's definition of volatile is completely right AIUI and the case reported by Peter B is definitely a very bad bug. Volatile operations are externally visible and must be executed in source-code order.) cheers, DaveK
Re: libgcc/static-object.mk weird error on powerpc-rtems
On 04/11/2011 17:33, Joel Sherrill wrote: Hi, I am testing powerpc-rtems on the head and have gotten a weird error compiling libgcc. It is definitely a regression from 4.6. I have no idea who might be the best person to help resolve this. /home2/joel/build/b-powerpc-gcc/powerpc-rtems4.11/libgcc [joel@rtbf64a libgcc]$ make /users/joel/test-gcc/gcc-svn/libgcc/static-object.mk:18: *** Unsupported file type: . Stop. Playing with the error message, it looks like the $o in the message is empty. What can I pass along to help get this debugged? Still having trouble with this? Try the makefile debugger: http://bashdb.sourceforge.net/remake/ You can step through the libgcc makefile and see where the empty entry comes from or just turn on enough tracing to see the return values from every string function executed. It may turn out to be stray whitespace in one of LIB2ADD, LIB2ADD_ST, LIB2ADDEHSTATIC, LIB2ADDEHSHARED, LIB2ADDEH or LIBUNWIND that needs trimming with $(strip). cheers, DaveK
Re: Failure to bootstrap trunk with --enable-threads=posix on cygwin since r180767
On 07/11/2011 18:39, Rainer Orth wrote: Christian Joensson christian.joensson@ writes: xgcc: error: unrecognized command line option ‘-pthread’ [...] Note the --enable-threads=posix. Backing off to revision 180766 does not yield this problem, while 180767 has the problem. I erroneously moved the use of i386/t-mingw-pthread to the cygwin case. As I just discovered! The following patch should correct this. Could you give it a try? 2011-11-07 Rainer Orth ro@ libgcc: * config.host (i[34567]86-*-cygwin*): Move i386/t-mingw-pthread ... (i[34567]86-*-mingw*): ... here. (x86_64-*-mingw*): ... here. That's not quite right (although it will probably work): @@ -605,6 +600,9 @@ i[34567]86-*-mingw*) win32) tmake_file=$tmake_file i386/t-gthr-win32 ;; + posix) + tmake_file=i386/t-mingw-pthread $tmake_file + ;; esac # This has to match the logic for DWARF2_UNWIND_INFO in gcc/config/i386/cygming.h if test x$enable_sjlj_exceptions = xyes; then @@ -626,6 +624,9 @@ x86_64-*-mingw*) win32) tmake_file=$tmake_file i386/t-gthr-win32 ;; + posix) + tmake_file=i386/t-mingw-pthread $tmake_file + ;; esac # This has to match the logic for DWARF2_UNWIND_INFO in gcc/config/i386/cygming.h if test x$enable_sjlj_exceptions = xyes; then Notice how in your additions, you prepend the t-mingw-pthread file to the list in $tmake_file rather than append it as the existing code does. Ordering of t-* files in $tmake_file is significant as there may be overrides and files should be listed from most generic to most target/os-specific, so please adjust those two hunks to match the way it's already being done. OK with that change. cheers, DaveK
Re: [4.5.1,PR42776] Backport LTO-COFF implementation.
On 30/10/2011 21:30, Gerald Pfeifer wrote: On Mon, 14 Jun 2010, Dave Korn wrote: * htdocs/gcc-4.5/changes.html: Remove explicit mentions of ELF format from LTO documentation. Ouch, I noticed this patch of yours never was applied, perhaps some misunderstanding between Richi and you (him assuming you'd go ahead and you waiting for his approval)? The patch still applies and looks good to me, so I went ahead and applied it on your behalf. Oh, I don't remember quite how it slipped through the cracks there, but thanks for finding it and applying it for us! cheers, DaveK
Re: Failure to bootstrap trunk with --enable-threads=posix on cygwin since r180767
On 08/11/2011 18:12, Rainer Orth wrote:
Dave Korn writes:
Notice how in your additions, you prepend the t-mingw-pthread file to the
list in $tmake_file rather than append it as the existing code does.
Ordering
of t-* files in $tmake_file is significant as there may be overrides and
files
should be listed from most generic to most target/os-specific, so please
adjust those two hunks to match the way it's already being done.
Huh? I've done it exactly the way it had been in gcc/config.gcc before
my patch series:
case ${enable_threads} in
| yes | win32) thread_file='win32'
tmake_file=${tmake_file} i386/t-gthr-win32
;;
posix)
thread_file='posix'
tmake_file=i386/t-mingw-pthread ${tmake_file}
;;
esac
Why should this suddenly be wrong in libgcc?
Hm. Well, it must have been inconsistent when it was added there in the
first place, so I guess since it hasn't been a problem yet there's no need to
fix it now. Patch is OK as-is then.
cheers,
DaveK
Re: [patch i386 mingw g++.dg gcc.dg]: Set -mms-bitfields as default for native windows targets
On 13/04/2011 11:49, Pedro Alves wrote: On Wednesday 13 April 2011 11:43:43, Kai Tietz wrote: This is a default ABI change (IIRC, when the option was introduced, it was left off as default so to not break the ABI). Shouldn't we advertise it somewhere? Yes, I did recently a lot of abi changing for mingw's targets. They all will need a nice description (and possible ways to get old default behavior) in changes.html I collect them for later. Or do you mean it should be noted earlier? As long as it's mentioned somewhere before a release, that's fine with me. (Though mentioning changes as you do them has better chances of something not getting forgotten, or in case you end up unavailable. Hope not! :-) ) Now we're coming up for a release did this happen? cheers, DaveK
[patch, win32, applied] Update libgcj version number in win32 crtbegin.
Hi list,
The win32 crtbegin code needs to know the full name of the libgcj DLL,
including in particular the trailing version suffix generated from the libtool
version info, and so far it's not autogenerated but needs to be manually
synced. This patch updates the two places where we have it defined. I'll do
a proper fix to parse the info out of the libjava/libtool-version file next
stage 1 but at least this keeps it up-to-date for forthcoming 4.7
Committed revision 181055, with the following changelog:
2011-11-06 Dave Korn dave.korn.cygwin@...
* config/i386/cygwin.h (LIBGCJ_SONAME): Updated to match recent
libgcj version bump.
* config/i386/mingw32.h (LIBGCJ_SONAME): Likewise.
cheers,
DaveK
Index: gcc/config/i386/cygwin.h
===
--- gcc/config/i386/cygwin.h (revision 181051)
+++ gcc/config/i386/cygwin.h (working copy)
@@ -136,5 +136,5 @@ along with GCC; see the file COPYING3. If not see
#define LIBGCC_SONAME cyggcc_s LIBGCC_EH_EXTN -1.dll
/* We should find a way to not have to update this manually. */
-#define LIBGCJ_SONAME cyggcj /*LIBGCC_EH_EXTN*/ -12.dll
+#define LIBGCJ_SONAME cyggcj /*LIBGCC_EH_EXTN*/ -13.dll
Index: gcc/config/i386/mingw32.h
===
--- gcc/config/i386/mingw32.h (revision 181051)
+++ gcc/config/i386/mingw32.h (working copy)
@@ -230,4 +230,4 @@ do { \
#define LIBGCC_SONAME libgcc_s LIBGCC_EH_EXTN -1.dll
/* We should find a way to not have to update this manually. */
-#define LIBGCJ_SONAME libgcj /*LIBGCC_EH_EXTN*/ -12.dll
+#define LIBGCJ_SONAME libgcj /*LIBGCC_EH_EXTN*/ -13.dll
Re: RFC: Add --plugin-gcc option to ar/nm
On 15/10/2011 23:44, H.J. Lu wrote: Hi, ---plugin option for ar/nm is very long. I am proposing to add a --plugin-gcc option. It can be implemented with 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4. 2. Define LTOPLUGINSONAME for ar/nm. 3. For --plugin-gcc, ar/nm call popen using environment variable GCC if set, or gcc with -print-prog-name=$LTOPLUGINSONAM to get plugin name. Any comments? Given the general environment variables are bad and to be avoided where possible rule we tend to follow, and the fact that it might often be more useful to check $CC rather than $GCC, how about letting --plugin-gcc take an optional argument, which is used in preference to both $GCC and plain gcc when provided? i.e. 3. For --plugin-gcc, ar/nm calls popen using - the optional argument to --plugin-gcc, if provided, or - environment variable GCC if set, or - gcc as the executable to launch, and with -print-prog-name=$LTOPLUGINSONAME as the sole command-line argument, to get the full path to the plugin. cheers, DaveK
Re: Merging gdc (GNU D Compiler) into gcc
On 05/10/2011 04:56, Iain Buclaw wrote: On 5 October 2011 00:10, Ian Lance Taylor i...@google.com wrote: Iain Buclaw ibuc...@ubuntu.com writes: First question that pops up after having a quick look is, are there any tips around for writing the scripts for the testsuite? I'm not too familiar with Dejagnu, and the current testsuite used for GDC D2 development is written in make. DejaGNU is too horrible for me to talk about. I can't recommend anything other than blind copying of existing scripts. :-) There are at least some docs online: http://gcc.gnu.org/wiki/TestCaseWriting http://gcc.gnu.org/wiki/HowToPrepareATestcase http://gcc.gnu.org/onlinedocs/gccint/Testsuites.html#Testsuites The DejaGnu manual is available online (http://www.gnu.org/s/dejagnu/#documentation), although it's not very GCC-specific; the most useful bit is the list of command-line options (http://www.gnu.org/s/dejagnu/manual/x844.html#optiondefs) that you can pass by setting RUNTESTFLAGS=... on the 'make check' command-line. If you're having real trouble understanding what's going on in a test script, setting RUNTESTFLAGS=-v -v -v --strace 30 will show you all the tcl commands being executed in the log file. And as Ian says, most people just copy how it's done in existing scripts. cheers, DaveK
Re: Volatile qualification on pointer and data
On 25/09/2011 13:56, David Brown wrote: There is a big difference between defining an object as const, and merely declaring it as const or accessing it as const. When you access it as const, you are saying /I/ won't change the object with this access. When you declare an object as const (such as an extern object), you are saying /I/ won't change this object. When you /define/ an object as const, as you do with a static const, you are saying this object is constant. It will never change value - you (the toolchain) can safely place it in read-only memory that cannot ever change value. And then you make it volatile, telling the compiler this object might change unexpectedly, or use values written to it unexpectedly. If someone could explain to me how this could have real-world usage, I think it would be easier for me (and others) to be sure of what it really means. Just because it's static doesn't mean the address can't escape: /* May read or write to dest, according to direction flag. */ extern void start_dma_xfer (void *dest, unsigned int size, bool direction, uint64_t bus_addr); /* We don't want to change this ourselves, and nor do we want the symbol to be externally visible. */ static const volatile char *dma_buffer[BUFFERSIZE]; [ ... later, in a function ... ] start_dma_transfer (dma_buffer[0], size, DIRECTION_DMA_TO_MEMORY, devaddr); A bit contrived perhaps, but start_dma_transfer (or some similar function) might be part of the OS or written in assembly and so necessarily C-type-safe. cheers, DaveK
Re: gcc detect multiple -o passed on one command line
On 06/05/2011 09:00, Andreas Schwab wrote: Ian Lance Taylor writes: The difference is that with -E the -o option is passed to cc1, whereas without it the -o option is passed to the assembler or the linker. The GNU assembler and linker both have the usual Unix behaviour of only using the last -o option. Nevertheless it might be a good idea to file a bug for binutils. Consistency is probably more important, and it helps in case of typos. In this case, I don't think consistency should win over maintaining long-established behaviour. I'm more inclined to say that cc1 should change to follow long-established *nix tradition. (I have absolutely found it useful on at least one occasion to be able to add a -o option into CFLAGS and know it would come last on the command-line and win.) cheers, DaveK
