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 the
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 d
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
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
Fro
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
>>
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?
>
&
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 unrela
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
ae6cf62861b5e9acb5
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
>>
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 p
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
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 C++
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
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
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
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 W
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 "SECUR
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
>> ---
>
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 yo
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
>>
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
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:
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.
>
>
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 dele
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
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 a
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,
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.
>>>
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!
>
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:
>>>>
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 suggeste
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.
>
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
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
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
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
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
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 i686-pc-mi
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 wouldn
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
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
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 a
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
> r
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
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
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
>
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 u
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 Mi
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 Mi
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
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;
>>
>> I tested this along w
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: Regenerat
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 CHECK_EXECUT
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 (t
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 mai
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 and
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
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
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 pat
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 performance and .text size
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 char
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 op
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
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
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 on M
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 th
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.
--- trunk/libgcc/config/i386/gthr
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 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 tha
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.
> * config/i386/driver-mingw32.
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
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 a
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
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 be
>> a GCC 8 stage 1 ite
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
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 ming
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
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
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
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
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
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 Makefile.in
Signed-off-b
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 have
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 also
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.
>>>
>>
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
&
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
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 t
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
>>
&
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 alt
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?
>>
&
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
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
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,
fixes fa
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
@@ -
On 7/19/2013 15:23, Yaakov (Cygwin/X) wrote:
> On 2013-07-14 20:15, JonY wrote:
>> 2013-03-08 Dave Korn
>>
>> * (gcc/config.gcc): Include Cygwin specific file.
>> * (gcc/config/i386/cygwin.h): Link shared libgcc by default.
>> * (gcc/config/i3
On 7/19/2013 15:21, Yaakov (Cygwin/X) wrote:
> On 2013-07-14 20:15, JonY wrote:
>> 2013-03-08 Yaakov Selkowitz
>>
>> * (gcc/testsuite/gcc.target/i386/pr25993.c): Skip unsupported test.
>
> This patch was Dave Korn's.
>
>
OK.
Changelog
2013-03
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 s
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 s
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 s
1 - 100 of 133 matches
Mail list logo
