Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro

On 9/22/20 8:50 AM, Jonathan Wakely wrote: > > I don't see a patch, or any previous email to the libstdc++ list. > > Please resend with the patch, CCing libstdc++@ > > Thanks. > > > Resent for the record. I've been told it might not be appropriate because some targets cannot link yet and

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

On 9/21/20 11:38 AM, Martin Liška wrote: > Sorry, it's not caused by your patch. It's our SUSE-specific package setup. > How does liblto_plugin.so.0.0.0 get loaded? I find only mentions of liblto_plugin.so. Is Suse GCC patched to use the versioned library? signature.asc Description: OpenPGP

Re: [PATCH] gcc: Make strchr return value pointers const

On 9/17/20 3:56 AM, Jeff Law wrote: > > If it's been ack'd by a maintainer, yes.  Jakub definitely qualifies as > a maintainer, so feel free to push it on Martin's behalf. > > > jeff Sure, it has been pushed, thanks all. signature.asc Description: OpenPGP digital signature

[PATCH] libstdc++: use lt_host_flags for libstdc++.la

For platforms like Mingw and Cygwin, cygwin refuses to generate the shared library without using -no-undefined. Attached patch makes sure the right flags are used, since libtool is already used to link libstdc++. Patch OK? From 4ba039687182fccd67e1170f89e259e1c4a58eeb Mon Sep 17 00:00:00 2001

Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro

On 9/13/20 3:37 PM, JonY wrote: > On 9/10/20 2:23 PM, JonY wrote: >> Do a link test instead of just a grep. The linker can >> support multiple targets, but not all targets can use it. >> >> Cygwin/MinGW ld can support ELF but the PE format for Windows itself >>

Re: [PATCH] libstdc++: use a link test to test for -Wl,-z,relro

On 9/10/20 2:23 PM, JonY wrote: > Do a link test instead of just a grep. The linker can > support multiple targets, but not all targets can use it. > > Cygwin/MinGW ld can support ELF but the PE format for Windows itself > does not support such a feature. Attached patch OK? > &

[PATCH] libstdc++: use a link test to test for -Wl,-z,relro

Do a link test instead of just a grep. The linker can support multiple targets, but not all targets can use it. Cygwin/MinGW ld can support ELF but the PE format for Windows itself does not support such a feature. Attached patch OK? I'm not confident with regenerating configure due to some

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

On 9/10/20 9:44 AM, Richard Biener wrote: >> >> I can confirm liblto is still loaded correctly from the logs, likewise >> renaming it away will cause an error. >> >> Seems to be fine on Linux. > > OK then. > > Thanks, > Richard. > Thanks for reviewing, pushed to master branch

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

On 9/9/20 7:32 AM, JonY wrote: > On 9/9/20 7:21 AM, Richard Biener wrote: >> On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches >> wrote: >>> >>> Hello, >>> >>> The lto plugis are tied to the built GCC anyway, so there isn't much >>

Re: [PATCH] Cygwin/MinGW: Do not version lto plugins

On 9/9/20 7:21 AM, Richard Biener wrote: > On Wed, Sep 9, 2020 at 2:28 AM JonY via Gcc-patches > wrote: >> >> Hello, >> >> The lto plugis are tied to the built GCC anyway, so there isn't much >> point to versioning them. > > In fact the lto plugin

[PATCH] Cygwin/MinGW: Do not version lto plugins

Hello, The lto plugis are tied to the built GCC anyway, so there isn't much point to versioning them. * gcc/config.host: Remove version string * lto-plugin/Makefile.am: Use libtool -avoid-version * lto-plugin/Makefile.in: Regenerate This patch has been in use with Cygwin gcc for a long time and

Re: [PATCH] gcc: Make strchr return value pointers const

On 9/4/20 12:47 PM, Martin Storsjö wrote: > Hi, > > On Fri, 4 Sep 2020, Jakub Jelinek wrote: > >> On Tue, Sep 01, 2020 at 04:01:42PM +0300, Martin Storsjö wrote: >>> This fixes compilation of codepaths for dos-like filesystems >>> with Clang. When built with clang, it treats C input files as

Re: [PATCH] gcc: Make strchr return value pointers const

On 9/1/20 1:01 PM, Martin Storsjö wrote: > This fixes compilation of codepaths for dos-like filesystems > with Clang. When built with clang, it treats C input files as C++ > when the compiler driver is invoked in C++ mode, triggering errors > when the return value of strchr() on a pointer to const

Re: [PATCH] Port libgccjit to Windows.

On 6/12/20 12:19 AM, JonY wrote: > On 6/11/20 10:02 PM, Nicolas Bértolo wrote: >> Hi, >> >> On 6/7/20 11:12 PM, JonY wrote: >>> Ideally, libtool is used so we get libgccjit-0.dll, unfortunately it is >>> not. So the only way to ABI version the dll would be to

Re: [PATCH] Port libgccjit to Windows.

On 6/11/20 10:02 PM, Nicolas Bértolo wrote: > Hi, > > On 6/7/20 11:12 PM, JonY wrote: >> Ideally, libtool is used so we get libgccjit-0.dll, unfortunately it is >> not. So the only way to ABI version the dll would be to use Unix style >> soname to mark when an AB

Re: [PATCH] Port libgccjit to Windows.

On 6/7/20 4:03 PM, Nicolas Bértolo wrote: > Hi, > > Sorry for the super late reply. > >> 1. Using .so on Windows for DLLs is fine. > > I know, but using the standard suffix for the platform seems better, IMHO. > It doesn't prevent applications from actually loading it. >> 2. The DLL name on

Re: [PATCH] Port libgccjit to Windows.

On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote: > On Thu, 2020-05-28 at 16:51 -0300, Nicolas Bértolo wrote: >>> I'm going to have to trust your Windows expertise here; the tempdir >>> code looks convoluted to me, but perhaps that's the only way to do >> it. >>> (Microsoft's docs for

Re: [PATCH] Ensure `-lmsvcrt` precede `-lkernel32`

On 5/29/20 2:04 PM, Liu Hao via Gcc-patches wrote: > 在 2020/5/29 22:01, Liu Hao 写道: >> This is necessary as libmsvcrt.a is not a pure import library, but >> also contains some functions that invoke others in KERNEL32.DLL. >> >> * config/i386/mingw32.h: Insert -lkernel32 after -lmsvcrt >> ---

Re: [PATCH] Port libgccjit to Windows.

On 5/28/20 8:46 PM, David Malcolm via Gcc-patches wrote: >>> I was able to successfully bootstrap and regression test with >>> your patch on x86_64-pc-linux-gnu. I also verified that the >>> result of >> "make >>> install" was not affected for my configuration. >> >> Great. >> >>> I've pushed

Re: [PATCH] i386: Make xmm16-xmm31 call used even in ms ABI

On 2/7/20 11:28 AM, Jakub Jelinek wrote: > On Fri, Feb 07, 2020 at 10:57:22AM +0000, JonY wrote: >>>> Is this patch testing still required? I just got back from traveling. >>> >>> Yes, our reading of the MS ABI docs show that xmm16-31 are to be call used >

Re: [PATCH] i386: Make xmm16-xmm31 call used even in ms ABI

On 2/6/20 6:07 AM, Jakub Jelinek wrote: > On Thu, Feb 06, 2020 at 01:00:36AM +0000, JonY wrote: >> On 2/4/20 11:42 AM, Jakub Jelinek wrote: >>> Hi! >>> >>> On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote: >>>> I guess that Comment

Re: [PATCH] x86-64: Pass aggregates with only float/double in GPRs for MS_ABI

On 2/7/20 3:23 AM, H.J. Lu wrote: > On Wed, Feb 05, 2020 at 09:51:14PM +0100, Uros Bizjak wrote: >> On Wed, Feb 5, 2020 at 6:59 PM H.J. Lu wrote: >>> >>> MS_ABI requires passing aggregates with only float/double in integer >>> registers. Checked gcc outputs against Clang and fixed: >>> >>> FAIL:

Re: [PATCH] i386: Make xmm16-xmm31 call used even in ms ABI

On 2/4/20 11:42 AM, Jakub Jelinek wrote: > Hi! > > On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote: >> I guess that Comment #9 patch form the PR should be trivially correct, >> but althouhg it looks obvious, I don't want to propose the patch since >> I have no means of testing it. >

Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows

On 7/3/19 12:55 PM, Liu Hao wrote: > 在 2019/7/2 下午8:27, Jonathan Wakely 写道: >> >> What do you mean by "unclosed thread"? If I read it correctly, the MSDN >> page >> refers to closing a handle (which makes sense), not closing a thread. >> > > Yes, it meant a thread which has terminated but not

Re: [PATCH] [MinGW] Set __USE_MINGW_ACCESS for C++ as well

On 3/18/19 10:31 PM, JonY wrote: > On 3/3/19 10:41 AM, Johannes Pfau wrote: >> We set __USE_MINGW_ACCESS for windows hosts to use MinGWs wrapper >> for the access function. The wrapper ensures that access behaves >> in the expected way (e.g. for special files, such as nul

Re: [PATCH] [MinGW] Set __USE_MINGW_ACCESS for C++ as well

On 3/3/19 10:41 AM, Johannes Pfau wrote: > We set __USE_MINGW_ACCESS for windows hosts to use MinGWs wrapper > for the access function. The wrapper ensures that access behaves > in the expected way (e.g. for special files, such as nul). > However, we now compile most sources with the C++ compiler

Re: [Patch] Bug 88521 - gcc 9.0 from r266355 miscompile x265 for mingw-w64 target

On 12/26/18 1:10 PM, Lokesh Janghel wrote: > Hi, > > Here is the patch for the issue. > Please let me know your thoughts. > > On Fri, Dec 21, 2018 at 3:16 PM JonY <10wa...@gmail.com> wrote: >> >> On 12/21/18 9:08 AM, Uros Bizjak wrote: >>> On Thu,

Re: [Patch] Bug 88521 - gcc 9.0 from r266355 miscompile x265 for mingw-w64 target

On 12/21/18 9:08 AM, Uros Bizjak wrote: > On Thu, Dec 20, 2018 at 1:09 PM Jakub Jelinek wrote: >> >> On Thu, Dec 20, 2018 at 01:42:15PM +0530, Lokesh Janghel wrote: >>> Hi Mateuszb, >>> >>> I tested with your proposition patch and it is working right. >>> I also added the patch with test case.

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 11/09/2018 10:48 AM, Alexandre Oliva wrote: > On Nov 8, 2018, JonY <10wa...@gmail.com> wrote: > >> No, no. By quick I just mean using -Wl,--large-address-aware on an >> existing gcc install, nothing complex. Sorry about not making it clear. > > Ah, good! >

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 11/08/2018 09:45 AM, Alexandre Oliva wrote: > On Nov 7, 2018, JonY <10wa...@gmail.com> wrote: > >> On 11/07/2018 08:34 AM, Alexandre Oliva wrote: >>> On Nov 1, 2018, JonY wrote: >>> >>>> Looks like it causes an error on 64bit: >>>>

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 11/07/2018 08:34 AM, Alexandre Oliva wrote: > On Nov 1, 2018, JonY wrote: > >> Looks like it causes an error on 64bit: >> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option >> '--large-address-aware' > > What does? The patch I suggested?

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 10/31/2018 10:39 PM, Alexandre Oliva wrote: > On Oct 12, 2018, Alexandre Oliva wrote: > >> * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define, >> based on MINGW_DEFAULT_LARGE_ADDR_AWARE. >> (LINK_SPEC): Insert it. >> * config/i386/mingw-264.h: Likewise. >

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 10/12/2018 05:56 AM, Alexandre Oliva wrote: > On Oct 11, 2018, JonY <10wa...@gmail.com> wrote: > >> On 10/11/2018 02:57 AM, NightStrike wrote: >>> >>> Except that options typically don't get removed, just deprecated. It >>> seems cleaner to me to

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 10/11/2018 02:57 AM, NightStrike wrote: > > Except that options typically don't get removed, just deprecated. It > seems cleaner to me to drop mingw from the name and make it default to > enabled for cygwin. > It is already enabled for Cygwin, but good point, --enable-large-address-aware it

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 10/10/2018 04:58 AM, Alexandre Oliva wrote: > On Oct 10, 2018, JonY <10wa...@gmail.com> wrote: > >> On 10/10/2018 03:24 AM, Alexandre Oliva wrote: >>> On Oct 9, 2018, JonY <10wa...@gmail.com> wrote: > >>> Now, if you wish it to affect Cygwin

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 10/10/2018 03:24 AM, Alexandre Oliva wrote: > On Oct 9, 2018, JonY <10wa...@gmail.com> wrote: > >> It is fine to turn it on by default in 32bit MinGW (i686-*-mingw*), but >> leave the defaults as is for others like Cygwin, I am not too sure of >> the effects f

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 10/09/2018 04:59 AM, Alexandre Oliva wrote: > On Oct 5, 2018, Joseph Myers wrote: > >> A new configure option needs documenting in install.texi. > > Ah, yes, thanks for the reminder. > > On Oct 6, 2018, JonY <10wa...@gmail.com> wrote: > >> They

Re: introduce --enable-mingw-full32 to default to --large-address-aware

On 10/05/2018 02:18 AM, Alexandre Oliva wrote: > Add a configure knob for mingw32 and 64 toolchains to default passing > --large-address-aware to the linker, when creating 32-bit binaries. > -Wl,--disable-large-address-aware can still reverse its effects. > > I've tested this with cross

Re: [PR c++/87137] GCC-8 Fix

On 08/30/2018 11:59 AM, Nathan Sidwell wrote: > On 08/29/2018 11:06 PM, Liu Hao wrote: > >> It is strictly an ABI break but I doubt whether code in real world >> that got broken by this bug ever exists. Usually when people expect >> consecutive bitfields to be packed into a single word they

Re: Two fixes for pretty-print.c for mingw-w64

On 08/14/2018 05:55 AM, Liu Hao wrote: > 在 2018/8/14 13:54, Liu Hao 写道: >> The two patches attached have addressed two issues in the ANSI escape >> sequence translator I sent before.  Please review, and consider >> backporting these to gcc-8-branch. >> >> >> >> > > And here are SVN changelogs for

Re: [Patch, Fortran] PR25829: Asynchronous I/O

On 06/04/2018 11:21 PM, JonY wrote: > On 06/03/2018 06:59 PM, Nicolas Koenig wrote: >> Hello everyone, >> >> this patch adds asynchronous I/O support. Thomas and I finally finished >> a feature-complete and debugged version, so here it is. In order to use >> asynch

Re: [Patch, Fortran] PR25829: Asynchronous I/O

On 06/03/2018 06:59 PM, Nicolas Koenig wrote: > Hello everyone, > > this patch adds asynchronous I/O support. Thomas and I finally finished > a feature-complete and debugged version, so here it is. In order to use > asynchronous I/O, it is still necessary to link against libpthread, > libgomp or

Re: [PATCH] Fix ms_struct/-mms-bitfields structure layout (PR target/52991)

On 02/28/2018 12:26 AM, Jakub Jelinek wrote: > Hi! > > The following patch fixes the reported ms_struct/-mms-bitfields structure > layout issues from PR52991. > > There are multiple issues, two of them introduced by the > https://gcc.gnu.org/ml/gcc-patches/2006-04/msg01064.html -mms-bitfields >

Re: [PING] Plugin support on Windows/MinGW

On 11/23/2017 11:34 AM, JonY wrote: > On 11/22/2017 11:14 AM, Boris Kolpackov wrote: >> JonY <10wa...@gmail.com> writes: >> >>> Is there a problem with using .so for internal libraries instead of >>> "dll"... >> >> I think not but I hav

Re: [PING] Plugin support on Windows/MinGW

On 11/22/2017 11:14 AM, Boris Kolpackov wrote: > JonY <10wa...@gmail.com> writes: > >> Is there a problem with using .so for internal libraries instead of >> "dll"... > > I think not but I haven't tested it. The problem with using .so instead >

Re: [PING] Plugin support on Windows/MinGW

On 11/21/2017 07:03 AM, Boris Kolpackov wrote: > Hi, > > I would like to ping this patch: > > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01040.html > > The changes are fairly conservative: they do not touch much of the > existing module implementation and plugin support on MinGW is disabled

Re: [PATCH][mingw] Enable colorized diagnostics

On 10/09/2017 01:07 PM, Liu Hao wrote: > On 2017/10/9 19:01, JonY wrote: >> On 10/08/2017 11:39 AM, Liu Hao wrote: >> >> I'm not sure if it should be enabled by default due to the interleaving >> problem, but seeing as the user has to go out to set GCC_COLORS to use

Re: [PATCH][mingw] Enable colorized diagnostics

On 10/08/2017 11:39 AM, Liu Hao wrote: > On 2017/9/28 4:09, Joseph Myers wrote: >> On Thu, 28 Sep 2017, Liu Hao wrote: >> >>> Colorized diagnostics used to be disabled for MinGW targets (on which >>> the macro `_WIN32` is defined), and this patch enables it. >> >> I'd hope this is all to do with

Re: [PATCH][mingw] Enable colorized diagnostics

On 09/27/2017 08:54 PM, Liu Hao wrote: > On 2017/9/28 4:09, Joseph Myers wrote: >> On Thu, 28 Sep 2017, Liu Hao wrote: >> >>> Colorized diagnostics used to be disabled for MinGW targets (on which >>> the macro `_WIN32` is defined), and this patch enables it. >> >> I'd hope this is all to do with

Re: [PATCH] Enable libitm DLL build on Cygwin/Mingw

On 08/09/2017 01:02 PM, JonY wrote: > Fixes libtool calls in libitm. Patch OK for trunk? > > 2017-08-09 Jonathan Yong <10wa...@gmail.com> > > * configure.ac: Check libtool flags. > * Makefile.am: Use lt_host_flags. > * configure: Regener

Re: [PATCH] [i386] PR 81850 Don't ignore -mabi=sysv on Cygwin/MinGW

On 08/22/2017 06:32 AM, Uros Bizjak wrote: > On Tue, Aug 22, 2017 at 4:10 AM, Daniel Santos > wrote: > >> This is a problem that occured because of this code in >> ix86_option_override_internal: >> >> if (!opts_set->x_ix86_abi) >> opts->x_ix86_abi = DEFAULT_ABI;

[PATCH] Enable libitm DLL build on Cygwin/Mingw

Fixes libtool calls in libitm. Patch OK for trunk? 2017-08-09 Jonathan Yong <10wa...@gmail.com> * configure.ac: Check libtool flags. * Makefile.am: Use lt_host_flags. * configure: Regenerated. * Makefile.in: Regenerated. * testsuite/Makefile.in:

[PATCH][cygming] Share mingw fset-stack-executable with cygwin

This patch is in use by Cygwin for years, upstream to GCC. Committed to trunk. * gcc/config/i386/mingw.opt (fset-stack-executable): Removed. * gcc/config/i386/cygming.opt (fset-stack-executable): Moved from mingw.opt. * gcc/config/i386/cygwin.h: Define

Re: Deprecate DBX/stabs?

On 07/21/2017 01:07 PM, Nathan Sidwell wrote: > [darwin, cygwin, rx maintainers, you might have an opinion] > Let's at least deprecate it. I attach a patch to do so. With the > patch, you'll get a note about dbx being deprecated whenever you use > stabs debugging on a system that prefers stabs

Re: [testsuite, i386] Always check for target i?86 and x86_64

On 06/20/2017 01:35 PM, Rainer Orth wrote: > JonY <10wa...@gmail.com> writes: > >> On 06/20/2017 01:01 PM, Rainer Orth wrote: >>> Given that there were no other comments, I've installed the patch. It >>> would still be nice if the Cygwin/MingW maintain

Re: [testsuite, i386] Always check for target i?86 and x86_64

On 06/20/2017 01:01 PM, Rainer Orth wrote: > > once I got the syntax right, this worked fine: it needs > > { target { ilp32 || lp64 } } > > instead ;-) > > I've also now managed to complete a Darwin/x86_64 bootstrap by locally > reverting the two culprit patches for PR bootstrap/81033

Re: Heads-Up: early LTO debug to land, breaking Mach-O / [X]COFF

On 05/12/2017 09:24 AM, Richard Biener wrote: > > This is a heads-up that I am in the process of implementing the last > of Jasons review comments on the dwarf2out parts of early LTO debug > support. I hope to post final patches early next week after thoroughly > re-testing everything. > > Note

Re: [wwwdocs] gcc-8/porting_to.html

On 03/23/2017 10:47 AM, Thomas Preudhomme wrote: > Ack. Please find updated patch as per suggestions. > > Best regards, > > Thomas > I've applied the changes to GCC 8 trunk as r247588. signature.asc Description: OpenPGP digital signature

Re: [PATCH] Fix cross compiling to x86_64-w64-mingw32

On 05/02/2017 12:11 PM, Hugo Beauzée-Luyssen wrote: > This patch fixes cross compiling to x86_64-w64-mingw32 > See https://github.com/Alexpux/MINGW-packages/issues/1580 and > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506 > > My apologies if I missed something in the contributing/sending a

Re: [PATCH v4 0/12] [i386] Improve 64-bit Microsoft to System V ABI pro/epilogues

On 05/01/2017 11:31 AM, Uros Bizjak wrote: > On Thu, Apr 27, 2017 at 10:04 AM, Daniel Santos > wrote: >> All of patches are concerned with 64-bit Microsoft ABI functions that call >> System V ABI function which clobbers RSI, RDI and XMM6-15 and are aimed at >> improving

[PATCH] Suppress ssp.c unused variable warning on mingw

Hi, This suppresses an unused variable warning for mingw*, patch OK? Index: libssp/ssp.c === --- libssp/ssp.c(revision 246630) +++ libssp/ssp.c(working copy) @@ -72,7 +72,6 @@ __guard_setup (void) { unsigned

Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues

On 03/30/2017 05:50 PM, Daniel Santos wrote: > I have finally completed all tests for Cygwin and MinGW both 32- & > 64-bit with no additional test failures. There are still 567 tests > failing both pre- and post-patch with error "error while loading shared > libraries: cyggfortran-4.dll: cannot

Re: [wwwdocs] gcc-8/porting_to.html

On 03/22/2017 05:39 PM, Thomas Preudhomme wrote: > Hi JonY, > > Sorry for the delay. Please find updated patch as per Gerald and you > suggestion. > > Is this ok for wwwdocs once [1] is committed in GCC 8 cycle? > > [1] https://gcc.gnu.org/ml/gcc-patches/2017-02/msg0115

Re: [PATCH] Suppress compiler warning in libgcc/unwind-seh.c

On 03/15/2017 04:12 AM, Jeff Law wrote: > On 03/01/2017 04:36 AM, JonY wrote: >> Patch OK? >> >> ChangeLog: >> * unwind-seh.c: Suppress warnings for RtlUnwindEx() calls. > You know this stuff better than anyone else working with GCC. If you > think this is

Re: [wwwdocs] gcc-8/porting_to.html

On 03/12/2017 02:07 PM, Gerald Pfeifer wrote: > On Thu, 9 Mar 2017, Thomas Preudhomme wrote: >> JonY: what about the attached patch to document the change of behavior >> of GCC on Windows depending on the configure option used? > > +MinGW issues > + > +GCC o

Re: [wwwdocs] gcc-8/porting_to.html

On 03/09/2017 11:22 AM, Thomas Preudhomme wrote: > Hi Jakub, > > I forgot to mention "ok for stage1?", my bad. JonY said he was queuing > the corresponding changes in GCC for stage1 so I was just trying to have > a complete story. I do not expect to commit this before

[PATCH] Fix libgfortran build for mingw*

Applied to trunk, tested with x86_64-w64-mingw32. Changelog: 2017-03-02 Jonathan Yong <10wa...@gmail.com> * config/i386/gthr-win32.h: Define NOGDI before windows.h include to prevent w32api CC_NONE macro clash with libgfortran. ---

Re: [PATCH] Suppress compiler warning in libgcc/unwind-seh.c

On 03/01/2017 11:36 AM, JonY wrote: > Patch OK? > > ChangeLog: > * unwind-seh.c: Suppress warnings for RtlUnwindEx() calls. > Applied, tested with x86_64-w64-mingw32 to trunk. signature.asc Description: OpenPGP digital signature

[PATCH] Suppress compiler warning in libgcc/unwind-seh.c

Patch OK? ChangeLog: * unwind-seh.c: Suppress warnings for RtlUnwindEx() calls. Index: libgcc/unwind-seh.c === --- libgcc/unwind-seh.c (revision 245806) +++ libgcc/unwind-seh.c (working copy) @@ -221,7 +221,7 @@ test is

Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows

On 02/17/2017 11:31 AM, Thomas Preudhomme wrote: > Here you are: > > 2017-01-24 Thomas Preud'homme > > * configure.ac (--enable-mingw-wildcard): Add new configurable > feature. > * configure: Regenerate. > * config.in: Regenerate. > *

Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows

On 02/14/2017 10:42 AM, JonY wrote: > On 02/14/2017 09:32 AM, Thomas Preudhomme wrote: >>> >>> Looks good, be sure to emphasize this option affects mingw hosted GCC >>> only, not the compiler output. >> >> I think that should be pretty clear in the latest

Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows

On 02/14/2017 09:32 AM, Thomas Preudhomme wrote: >> >> Looks good, be sure to emphasize this option affects mingw hosted GCC >> only, not the compiler output. > > I think that should be pretty clear in the latest version of the patch, > doc/install.texi contains: > > "Note that this option only

Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues

On 02/10/2017 05:23 PM, Daniel Santos wrote: > On 02/10/2017 05:34 AM, JonY wrote: >> Hi, >> mingw-w64 itself does not use any ms_abi/sysv_abi marked functions >> internally, so it should be unaffected. I don't think Cygwin uses any >> either, but I need to double ch

Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues

On 02/10/2017 10:32 AM, Uros Bizjak wrote: > On Tue, Feb 7, 2017 at 7:38 PM, Daniel Santos wrote: > >> Uros or Jan, >> Please take this as a ping, as I never bothered pinging after submitting v2 >> since I found a few more issues with it. :) Although I realize this would

Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows

On 01/26/2017 01:04 PM, Thomas Preudhomme wrote: > Hi JonY, > > On 19/01/17 01:37, JonY wrote: >> On 01/18/2017 09:48 AM, Thomas Preudhomme wrote: >>> By default, wildcard support on Windows for programs compiled with mingw >>> depends on how the mingw runtime

Re: [PATCH, GCC/x86 mingw32] Add configure option to force wildcard behavior on Windows

On 01/18/2017 09:48 AM, Thomas Preudhomme wrote: > By default, wildcard support on Windows for programs compiled with mingw > depends on how the mingw runtime was configured. This means if one wants > to build GCC for Windows with a consistent behavior with Wildcard > (enabled or disabled) the

Re: [PATCH][GCC] Fix native Windows x86 bootstrap failure with self test

On 11/4/2016 21:22, Tamar Christina wrote: > Hi all, > > The GCC self-test added in r237144 breaks the > native Windows x86 builds (e.g. mingw-w64). > This fixes (PR78196) by explicitly adding /dev/null as > the output file to the GCC self test. > > The test essentially does `-xc -S -c /dev/null

Re: [Patch] Disable text mode translation in ada for Cygwin

On 8/19/2016 20:49, Arnaud Charlet wrote: >>> Text mode translation should not be done for Cygwin, especially since it >>> does not >>> support unicode setmode calls. This also fixes ada builds for Cygwin. >>> >>> OK for trunk? >> >> Ping? > > Can you send the link to your original submission for

Re: [Patch] Disable text mode translation in ada for Cygwin

On 5/26/2016 20:36, JonY wrote: > Text mode translation should not be done for Cygwin, especially since it does > not > support unicode setmode calls. This also fixes ada builds for Cygwin. > > OK for trunk? Ping? signature.asc Description: OpenPGP digital signature

Re: [PATCH] Add missing OBJCOPY variable to Makefile.in

On 7/14/2016 06:22, Jeff Law wrote: > On 07/03/2016 05:56 AM, JonY wrote: >> This patch allows OBJCOPY to be set by configure. It was missing in >> Makefile.in. >> >> Patch OK? > With a ChangeLog and verification that some host/target combination > s

Re: [PATCH] Add missing OBJCOPY variable to Makefile.in

On 7/14/2016 06:22, Jeff Law wrote: > On 07/03/2016 05:56 AM, JonY wrote: >> This patch allows OBJCOPY to be set by configure. It was missing in >> Makefile.in. >> >> Patch OK? > With a ChangeLog and verification that some host/target combination > still builds

[PATCH] Add missing OBJCOPY variable to Makefile.in

This patch allows OBJCOPY to be set by configure. It was missing in Makefile.in. Patch OK? From c7b2b18116cd0ba73ff585299b5190a05e267d3f Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sat, 26 Mar 2016 12:32:18 +0100 Subject: [PATCH] Add missing OBJCOPY variable to

Re: [Patch] Disable text mode translation in ada for Cygwin

On 7/1/2016 20:00, Arnaud Charlet wrote: >> >> ping2? Is there a dedicated list for ADA patches? > > This list is for submitting patches, which you have done, it is not > really about pinging for commits, which should preferably be done by > the submitter, after proper testing. > > I do not

Re: [Patch] Disable text mode translation in ada for Cygwin

On 6/1/2016 18:27, JonY wrote: > On 5/27/2016 06:25, JonY wrote: >> On 5/26/2016 21:55, Arnaud Charlet wrote: >>>> Text mode translation should not be done for Cygwin, especially since it >>>> does not >>>> support unicode setmode calls. This a

Re: [Patch] Disable text mode translation in ada for Cygwin

On 5/27/2016 06:25, JonY wrote: > On 5/26/2016 21:55, Arnaud Charlet wrote: >>> Text mode translation should not be done for Cygwin, especially since it >>> does not >>> support unicode setmode calls. This also fixes ada builds for Cygwin. >>> >>

Re: Revert gcc r227962

On 5/23/2016 16:56, JonY wrote: > On 5/20/2016 06:36, JonY wrote: >> On 5/20/2016 02:11, Jeff Law wrote: >>> So if we make this change (revert 227962), my understanding is that >>> cygwin bootstraps will fail because they won't find kernel32 and perhaps >&g

Re: [Patch] Disable text mode translation in ada for Cygwin

On 5/26/2016 21:55, Arnaud Charlet wrote: >> Text mode translation should not be done for Cygwin, especially since it >> does not >> support unicode setmode calls. This also fixes ada builds for Cygwin. >> >> OK for trunk? > > OK, thanks. > Can someone please commit this? I don't have SVN write

[Patch] Disable text mode translation in ada for Cygwin

Text mode translation should not be done for Cygwin, especially since it does not support unicode setmode calls. This also fixes ada builds for Cygwin. OK for trunk? gcc/ada/ChangeLog: * sysdep.c (__gnat_set_binary_mode, __gnat_set_text_mode, __gnat_set_mode): Disable text mode

Re: Revert gcc r227962

On 5/20/2016 06:36, JonY wrote: > On 5/20/2016 02:11, Jeff Law wrote: >> So if we make this change (revert 227962), my understanding is that >> cygwin bootstraps will fail because they won't find kernel32 and perhaps >> other libraries. >> >> Jeff >> &g

Re: Revert gcc r227962

On 5/20/2016 02:11, Jeff Law wrote: > So if we make this change (revert 227962), my understanding is that > cygwin bootstraps will fail because they won't find kernel32 and perhaps > other libraries. > > Jeff > I'll need to double check with trunk but gcc-5.3.0 built OK without it. The other

Re: Revert gcc r227962

On 2/27/2016 05:26, Jeff Law wrote: > On 02/26/2016 04:04 AM, JonY wrote: >> Hi, >> >> I've submitted a patch that was committed as r227962, it causes some >> unintended side effects (namely libuuid on Cygwin). Can someone please >> revert? >> >&g

Revert gcc r227962

Hi, I've submitted a patch that was committed as r227962, it causes some unintended side effects (namely libuuid on Cygwin). Can someone please revert? Kai still needs some time to setup his gcc development environment. Thanks. signature.asc Description: OpenPGP digital signature

Re: [PATCH] Fix Cygwin bootstrap failing to find win32 libraries

On 9/21/2015 02:05, Kai Tietz wrote: > 2015-09-16 13:42 GMT+02:00 JonY <10wa...@gmail.com>: >> libgcc is failing to find kerne32 etc during the 2nd stage when >> bootstraping, explicitly add w32api directory to search path. >> >> Patch OK? >> >> diff

Re: [PATCH] Fix Cygwin bootstrap failing to find win32 libraries

On 9/20/2015 02:52, Kai Tietz wrote: > Hello JonY, > > patch is ok with proper ChangeLog. > > Thanks, > Kai > Am 16.09.2015 13:42 schrieb "JonY" <10wa...@gmail.com>: > Explicitly search sysroot/usr/lib/32api for additional win32 libraries,

[PATCH] Fix Cygwin bootstrap failing to find win32 libraries

libgcc is failing to find kerne32 etc during the 2nd stage when bootstraping, explicitly add w32api directory to search path. Patch OK? diff --git a/gcc/config/i386/cygwin.h b/gcc/config/i386/cygwin.h index 2a2a0bf..fd3bc0a 100644 --- a/gcc/config/i386/cygwin.h +++ b/gcc/config/i386/cygwin.h @@

Re: Minor Cygwin patches

On 7/19/2013 15:21, Yaakov (Cygwin/X) wrote: On 2013-07-14 20:15, JonY wrote: 2013-03-08 Yaakov Selkowitz yselkow...@users.sourceforge.net * (gcc/testsuite/gcc.target/i386/pr25993.c): Skip unsupported test. This patch was Dave Korn's. OK. Changelog 2013-03-08 Dave Korn

Re: Minor Cygwin patches

On 7/19/2013 15:23, Yaakov (Cygwin/X) wrote: On 2013-07-14 20:15, JonY wrote: 2013-03-08 Dave Korn dave.korn.cyg...@gmail.com * (gcc/config.gcc): Include Cygwin specific file. * (gcc/config/i386/cygwin.h): Link shared libgcc by default. * (gcc/config/i386/cygwin.h): Add

Re: Minor Cygwin patches

On 7/15/2013 06:02, Kai Tietz wrote: 2013/7/13 JonY 10wa...@gmail.com: On 7/10/2013 20:43, JonY wrote: Hi, Attached are some minor patches, comments? Kai, ping? Please sent each patch as separate mail, and please add ChangeLogs for them too. Additionally it would be fine to read

Re: Minor Cygwin patches

On 7/15/2013 06:02, Kai Tietz wrote: 2013/7/13 JonY 10wa...@gmail.com: On 7/10/2013 20:43, JonY wrote: Hi, Attached are some minor patches, comments? Kai, ping? Please sent each patch as separate mail, and please add ChangeLogs for them too. Additionally it would be fine to read

Re: Minor Cygwin patches

On 7/15/2013 06:02, Kai Tietz wrote: 2013/7/13 JonY 10wa...@gmail.com: On 7/10/2013 20:43, JonY wrote: Hi, Attached are some minor patches, comments? Kai, ping? Please sent each patch as separate mail, and please add ChangeLogs for them too. Additionally it would be fine to read

  1   2   >