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=detailitem&item_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: [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
>
> * 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: [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 : >> On 23/03/2013 00:24, Kai Tietz wrote: >>> 2013/3/23 Dave Korn : >>>> 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: [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 :
>> 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 libgcc]: Adjust cygming-crtbegin code to use weak
On 23/03/2013 00:27, Kai Tietz wrote: > 2013/3/23 Dave Korn : >> On 23/03/2013 00:08, Kai Tietz wrote: >>> 2013/3/23 Dave Korn : >>>> 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 cygwin64]: Add and adjust some initial sources for x64 cygwin
On 23/03/2013 00:24, Kai Tietz wrote: > 2013/3/23 Dave Korn : >> 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]: 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: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 libgcc]: Adjust cygming-crtbegin code to use weak
On 23/03/2013 00:08, Kai Tietz wrote: > 2013/3/23 Dave Korn : >> 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 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 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 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 > > * 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][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 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 >> >> * 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. +Operating Systems + +Windows (Cygwin) + +Executables 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. + +
[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
* 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: [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
> +/* 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 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] 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] 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 Pavel Labushev >* 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 * 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: [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: [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: [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: [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 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++.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: [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
[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.adb
Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)
On 04/12/2011 17:34, Eric Botcazou wrote:
> Ouch. :-) Please do something like this:
Righto, tweaked as you ask, updated patch attached for reference.
gcc/ada/ChangeLog:
2011-12-06 Dave Korn Index: gcc-interface/Makefile.in
===
--- gcc-interface/Makefile.in (revision 182064)
+++ gcc-interface/Makefile.in (working copy)
@@ -1580,18 +1580,32 @@ ifeq ($(strip $(filter-out avr none powerpc% eabis
indepsw.adb
+#else
+#define WIN_SETMODE _setmode
+#endif
+
void
__gnat_set_binary_mode (int handle)
{
- _setmode (handle, O_BINARY);
+ WIN_SETMODE (handle, O_BINARY);
}
void
__gnat_set_text_mode (int handle)
{
- _setmode (handle, O_TEXT);
+ WIN_SETMODE (handle, O_TEXT);
}
-#ifdef __MINGW32__
-#include
+#ifdef __CYGWIN__
-/* Return the name of the tty. Under windows there is no name for
- the tty, so this function, if connected to a tty, returns the generic name
- "console". */
-
char *
__gnat_ttyname (int filedes)
{
- if (isatty (filedes))
-return "console";
- else
-return NULL;
+ extern char *ttyname (int);
+
+ return ttyname (filedes);
}
+#endif /* __CYGWIN__ */
+
+#if defined (__CYGWIN__) || defined (__MINGW32__)
+#include
+
#ifndef RTX
int __gnat_is_windows_xp (void);
@@ -178,7 +184,7 @@ __gnat_is_windows_xp (void)
return is_win_xp;
}
-#endif
+#endif /* !RTX */
/* Get the bounds of the stack. The stack pointer is supposed to be
initialized to BASE when a thread is created and the stack can be extended
@@ -198,8 +204,25 @@ __gnat_get_stack_bounds (void **base, void **limit
*limit = tib->StackLimit;
}
-#endif /* !__MINGW32__ */
+#endif /* __CYGWIN__ || __MINGW32__ */
+#ifdef __MINGW32__
+
+/* Return the name of the tty. Under windows there is no name for
+ the tty, so this function, if connected to a tty, returns the generic name
+ "console". */
+
+char *
+__gnat_ttyname (int filedes)
+{
+ if (isatty (filedes))
+return "console";
+ else
+return NULL;
+}
+
+#endif /* __MINGW32__ */
+
#else
const char __gnat_text_translation_required = 0;
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.adb
+#else
+#define WIN_SETMODE _setmode
+#endif
+
void
__gnat_set_binary_mode (int handle)
{
- _setmode (handle, O_BINARY);
+ WIN_SETMODE (handle, O_BINARY);
}
void
__gnat_set_text_mode (int handle)
{
- _setmode (handle, O_TEXT);
+ WIN_SETMODE (handle, O_TEXT);
}
-#ifdef __MINGW32__
-#include
+#ifdef __CYGWIN__
-/* Return the name of the tty. Under windows there is no name for
- the tty, so this function, if connected to a tty, returns the generic name
- "console". */
-
char *
__gnat_ttyname (int filedes)
{
- if (isatty (filedes))
-return "console";
- else
-return NULL;
+ extern char *ttyname (int);
+
+ return ttyname (filedes);
}
+#endif /* __CYGWIN__ */
+
+#if defined (__CYGWIN__) || defined (__MINGW32__)
+#include
+
#ifndef RTX
int __gnat_is_windows_xp (void);
@@ -178,7 +184,7 @@ __gnat_is_windows_xp (void)
return is_win_xp;
}
-#endif
+#endif /* !RTX */
/* Get the bounds of the stack. The stack pointer is supposed to be
initialized to BASE when a thread is created and the stack can be extended
@@ -198,8 +204,25 @@ __gnat_get_stack_bounds (void **base, void **limit
*limit = tib->StackLimit;
}
-#endif /* !__MINGW32__ */
+#endif /* __CYGWIN__ || __MINGW32__ */
+#ifdef __MINGW32__
+
+/* Return the name of the tty. Under windows there is no name for
+ the tty, so this function, if connected to a tty, returns the generic name
+ "console".
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
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: [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 07/11/2011 18:39, Rainer Orth wrote: > Christian Joensson >> 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 > 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
[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 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: [toplevel] cleanup mh-cygwin
On 24/03/2011 17:11, Paolo Bonzini wrote: > The cygwin host fragment is using obsolete variables and constructs, > modernize it. > > Committed to gcc and (shortly) src. Thanks, top-level stuff is a bit of a mystery to me :) cheers, DaveK
Re: RFC: Issue about assumption of DOSish file-system for cygwin
On 22/03/2011 11:00, Kai Tietz wrote: > I noticed this issue while working on those directory-separator thing > for DOSish file-systems, and somehow this looks odd to me. For some > reason the filenames.h header assumes for cygwin DOSish file-system, > but in fact cygwin uses POSIXish file-system. I assume this definition > was caused by the times cygwin compiler had -mno-cygwin option, but > well I think we should correct this by following patch. > Dave, might it be that I am overlooking here something obvious, why > cygwin should assume DOSish filesystem? Cygwin works in mixed mode, it can use both dos and posix paths; it'll even preserve them into e.g. things like debug info: > $ as C:/hello.s -o C:/hello2.o -g > > $ ls C:/hello.s C:/hello2.o -la > -rw-r--r-- 1 DKAdmin None 437 Mar 22 17:56 C:/hello.s > -rw-r--r-- 1 DKAdmin None 1084 Mar 22 17:57 C:/hello2.o > > $ nm C:/hello2.o > b .bss > d .data > r .rdata > N .stab > N .stabstr > t .text > U ___main > T _main > U _puts > > $ objdump -g C:/hello2.o > > C:/hello2.o: file format pe-i386 > > C:/hello.s: > /* file C:/hello.s line 10 addr 0x0 */ > /* file C:/hello.s line 11 addr 0x4 */ > /* file C:/hello.s line 12 addr 0x7 */ > /* file C:/hello.s line 13 addr 0xa */ > /* file C:/hello.s line 14 addr 0xb */ > /* file C:/hello.s line 15 addr 0xd */ > /* file C:/hello.s line 16 addr 0xe */ > /* file C:/hello.s line 17 addr 0x11 */ > /* file C:/hello.s line 18 addr 0x16 */ > /* file C:/hello.s line 19 addr 0x1d */ > /* file C:/hello.s line 20 addr 0x22 */ > /* file C:/hello.s line 21 addr 0x27 */ > /* file C:/hello.s line 22 addr 0x2a */ > /* file C:/hello.s line 23 addr 0x2b */ > /* file C:/hello.s line 24 addr 0x2c */ > /* file C:/hello.s line 25 addr 0x2f */ > > $ as /cygdrive/c/hello.s -o C:/hello3.o -g > > $ objdump -g C:/hello3.o > > C:/hello3.o: file format pe-i386 > > /cygdrive/c/hello.s: > /* file /cygdrive/c/hello.s line 10 addr 0x0 */ > /* file /cygdrive/c/hello.s line 11 addr 0x4 */ > /* file /cygdrive/c/hello.s line 12 addr 0x7 */ > /* file /cygdrive/c/hello.s line 13 addr 0xa */ > /* file /cygdrive/c/hello.s line 14 addr 0xb */ > /* file /cygdrive/c/hello.s line 15 addr 0xd */ > /* file /cygdrive/c/hello.s line 16 addr 0xe */ > /* file /cygdrive/c/hello.s line 17 addr 0x11 */ > /* file /cygdrive/c/hello.s line 18 addr 0x16 */ > /* file /cygdrive/c/hello.s line 19 addr 0x1d */ > /* file /cygdrive/c/hello.s line 20 addr 0x22 */ > /* file /cygdrive/c/hello.s line 21 addr 0x27 */ > /* file /cygdrive/c/hello.s line 22 addr 0x2a */ > /* file /cygdrive/c/hello.s line 23 addr 0x2b */ > /* file /cygdrive/c/hello.s line 24 addr 0x2c */ > /* file /cygdrive/c/hello.s line 25 addr 0x2f */ > > $ cheers, DaveK
Re: [RFA] libiberty/hashtab.c, higher_prime_index: avoid array overrun
On 03/03/2011 23:00, Mike Stump wrote: > On Mar 3, 2011, at 2:26 PM, Michael Snyder wrote: >> DJ Delorie wrote: As written, the function will access element [30] of a 30-element array. >>> Um, no? >> Y-uh-huh! > > fight fight fight... :-) There can be only one. I was just wondering whether now would be a good time to mention that having prime-sized hash tables is only a workaround against the danger of someone providing an inadequate hash function implementation in the first place? cheers, DaveK
