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

[JonY via Gcc-patches]

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 therefore will fail incorrectly.

Currently, the linker support is misdetected since binutils can support
multiple targets. MinGW/Cygwin PE formats don't support such a flag.
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 22 Mar 2020 01:59:37 + (+0800)
Subject: libstdc++: use a link test to test for -Wl,-z,relro
X-Git-Url: 
https://repo.or.cz/gcc/cygwin-gcc.git/commitdiff_plain/1b20e03e7468760828bfc70fc5e811b5b3738adf

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.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index bc7d137dc74..209aa3a91f3 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -274,7 +274,16 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES], [
   ac_ld_relro=no
   if test x"$with_gnu_ld" = x"yes"; then
 AC_MSG_CHECKING([for ld that supports -Wl,-z,relro])
-cxx_z_relo=`$LD -v --help 2>/dev/null | grep "z relro"`
+ac_save_ldflags="$LDFLAGS"
+LDFLAGS="$LDFLAGS -Wl,-z,relro"
+AC_LINK_IFELSE([
+  AC_LANG_SOURCE(
+[[int main() { return 0; }]]
+  )],
+  [cxx_z_relo="1"],
+  [cxx_z_relo=""])
+   LDFLAGS="$ac_save_ldflags"
+
 if test -n "$cxx_z_relo"; then
   OPT_LDFLAGS="-Wl,-z,relro"
   ac_ld_relro=yes


signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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 digital signature

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

[JonY via Gcc-patches]

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

[JonY via Gcc-patches]

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
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 22 Mar 2020 09:56:58 +0800
Subject: [PATCH 1/1] libstdc++: use lt_host_flags for libstdc++.la

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---
 libstdc++-v3/src/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/src/Makefile.am b/libstdc++-v3/src/Makefile.am
index a139adc81b3..498f533f3d3 100644
--- a/libstdc++-v3/src/Makefile.am
+++ b/libstdc++-v3/src/Makefile.am
@@ -107,7 +107,7 @@ libstdc___la_DEPENDENCIES = \
 libstdc___la_LDFLAGS = \
 	-version-info $(libtool_VERSION) ${version_arg} -lm
 
-libstdc___la_LINK = $(CXXLINK) $(libstdc___la_LDFLAGS)
+libstdc___la_LINK = $(CXXLINK) $(libstdc___la_LDFLAGS) $(lt_host_flags)
 
 # Use special rules for compatibility-ldbl.cc compilation, as we need to
 # pass -mlong-double-64.
-- 
2.11.4.GIT



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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
>> does not support such a feature. Attached patch OK?
>>
>> I'm not confident with regenerating configure due to some unrelated
>> changes added, can someone else help with that?
>>
> 
> Ping?
> 

Ping 2?



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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?
> 
> I'm not confident with regenerating configure due to some unrelated
> changes added, can someone else help with that?
> 

Ping?



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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 unrelated
changes added, can someone else help with that?
From: Jonathan Yong <10wa...@gmail.com>
Date: Sun, 22 Mar 2020 01:59:37 + (+0800)
Subject: libstdc++: use a link test to test for -Wl,-z,relro
X-Git-Url: 
https://repo.or.cz/gcc/cygwin-gcc.git/commitdiff_plain/1b20e03e7468760828bfc70fc5e811b5b3738adf

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.

Signed-off-by: Jonathan Yong <10wa...@gmail.com>
---

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index bc7d137dc74..209aa3a91f3 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -274,7 +274,16 @@ AC_DEFUN([GLIBCXX_CHECK_LINKER_FEATURES], [
   ac_ld_relro=no
   if test x"$with_gnu_ld" = x"yes"; then
 AC_MSG_CHECKING([for ld that supports -Wl,-z,relro])
-cxx_z_relo=`$LD -v --help 2>/dev/null | grep "z relro"`
+ac_save_ldflags="$LDFLAGS"
+LDFLAGS="$LDFLAGS -Wl,-z,relro"
+AC_LINK_IFELSE([
+  AC_LANG_SOURCE(
+[[int main() { return 0; }]]
+  )],
+  [cxx_z_relo="1"],
+  [cxx_z_relo=""])
+   LDFLAGS="$ac_save_ldflags"
+
 if test -n "$cxx_z_relo"; then
   OPT_LDFLAGS="-Wl,-z,relro"
   ac_ld_relro=yes


signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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
ae6cf62861b5e9acb518b016ddbe7f783206f65f.



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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
>>> point to versioning them.
>>
>> In fact the lto plugins are not tied to the built GCCs very much, instead
>> we try to ensure compatibility so that a single plugin can be used with
>> multiple GCC versions.
>>
> 
> I see, I was not aware of this.
> 
>>> * 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 should be
>>> pushed upstream. Patch OK?
>>
>> The libtool docs are not very specific here but does this affect the
>> result for Linux ELF platforms at all?
> 
> With current builds:
> 
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.la
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0
> /usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0.0.0
> 
> With -avoid-version it will only generate liblto_plugin.so, from
> gcc/config.host, it is already what is loaded.
> 
> I will do a native linux build to confirm this.
> 

I did a bootstrap build of gcc on Linux and it produced the following
after installing:

libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.la
libexec/gcc/x86_64-pc-linux-gnu/11.0.0/liblto_plugin.so

I tested with the following command:

echo 'main(){}' | strace -f -o gcc.log -- ./inst/bin/gcc -xc - -v
-fuse-linker-plugin -o aa.out

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.



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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 plugins are not tied to the built GCCs very much, instead
> we try to ensure compatibility so that a single plugin can be used with
> multiple GCC versions.
> 

I see, I was not aware of this.

>> * 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 should be
>> pushed upstream. Patch OK?
> 
> The libtool docs are not very specific here but does this affect the
> result for Linux ELF platforms at all?

With current builds:

/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.la
/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so
/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0
/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/liblto_plugin.so.0.0.0

With -avoid-version it will only generate liblto_plugin.so, from
gcc/config.host, it is already what is loaded.

I will do a native linux build to confirm this.



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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 should be
pushed upstream. Patch OK?

From 6bf6b87887a8a5eb53ad409cd4aa32cb1ac50786 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Sat, 28 Jun 2014 09:35:02 +0800
Subject: [PATCH 1/1] Cygwin/MinGW: Do not version lto plugins

---
 gcc/config.host| 6 +++---
 lto-plugin/Makefile.am | 2 +-
 lto-plugin/Makefile.in | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gcc/config.host b/gcc/config.host
index 84f0433e2ad..373d5efd8da 100644
--- a/gcc/config.host
+++ b/gcc/config.host
@@ -232,7 +232,7 @@ case ${host} in
 out_host_hook_obj=host-cygwin.o
 host_xmake_file="${host_xmake_file} i386/x-cygwin"
 host_exeext=.exe
-host_lto_plugin_soname=cyglto_plugin-0.dll
+host_lto_plugin_soname=cyglto_plugin.dll
 ;;
   i[34567]86-*-mingw32*)
 host_xm_file=i386/xm-mingw32.h
@@ -240,7 +240,7 @@ case ${host} in
 host_exeext=.exe
 out_host_hook_obj=host-mingw32.o
 host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
-host_lto_plugin_soname=liblto_plugin-0.dll
+host_lto_plugin_soname=liblto_plugin.dll
 ;;
   x86_64-*-mingw*)
 use_long_long_for_widest_fast_int=yes
@@ -249,7 +249,7 @@ case ${host} in
 host_exeext=.exe
 out_host_hook_obj=host-mingw32.o
 host_extra_gcc_objs="${host_extra_gcc_objs} driver-mingw32.o"
-host_lto_plugin_soname=liblto_plugin-0.dll
+host_lto_plugin_soname=liblto_plugin.dll
 ;;
   i[34567]86-*-darwin* | x86_64-*-darwin*)
 out_host_hook_obj="${out_host_hook_obj} host-i386-darwin.o"
diff --git a/lto-plugin/Makefile.am b/lto-plugin/Makefile.am
index ba5882df7a7..204b25f45ef 100644
--- a/lto-plugin/Makefile.am
+++ b/lto-plugin/Makefile.am
@@ -21,7 +21,7 @@ in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), 
$(gcc_build_dir)/$(lib))
 liblto_plugin_la_SOURCES = lto-plugin.c
 # Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS.
 liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) \
-   $(lt_host_flags) -module -bindir $(libexecsubdir)
+   $(lt_host_flags) -module -avoid-version -bindir $(libexecsubdir)
 # Can be simplified when libiberty becomes a normal convenience library.
 libiberty = $(with_libiberty)/libiberty.a
 libiberty_noasan = $(with_libiberty)/noasan/libiberty.a
diff --git a/lto-plugin/Makefile.in b/lto-plugin/Makefile.in
index 7da7cd26dbf..834699b439e 100644
--- a/lto-plugin/Makefile.in
+++ b/lto-plugin/Makefile.in
@@ -350,7 +350,7 @@ libexecsub_LTLIBRARIES = liblto_plugin.la
 in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), 
$(gcc_build_dir)/$(lib))
 liblto_plugin_la_SOURCES = lto-plugin.c
 # Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS.
-liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) $(lt_host_flags) -module \
+liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) $(lt_host_flags) -module 
-avoid-version \
-bindir $(libexecsubdir) $(if $(wildcard \
$(libiberty_noasan)),, $(if $(wildcard \
$(libiberty_pic)),,-Wc,$(libiberty)))
-- 
2.11.4.GIT



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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++
>>> when the compiler driver is invoked in C++ mode, triggering errors
>>> when the return value of strchr() on a pointer to const is assigned
>>> to a pointer to non-const variable.
>>
>> Not really specific to clang, e.g. glibc does that in its headers too
>> as the C++ standard mandates that (and I guess mingw should do that too).
>>
>>> This matches similar variables outside of the ifdefs for dos-like
>>> path handling.
>>>
>>> 2020-09-01  Martin Storsjö  
>>>
>>> gcc/Changelog:
>>>     * dwarf2out.c (file_name_acquire): Make a strchr return value
>>>     pointer to const.
>>>
>>> libcpp/Changelog:
>>>     * files.c (remap_filename): Make a strchr return value pointer
>>>     to const.
>>
>> LGTM.  And it is short enough not to need copyright assignment, so ok for
>> trunk.
> 
> Thanks! Can someone commit this for me?
> 
> // Martin

Ping can anyone commit this?

Are platform maintainers allowed to push general changes like these? If
so I can push soon.



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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 is assigned
> to a pointer to non-const variable.
> 

Ping any reviewers?



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Port libgccjit to Windows.

[JonY via Gcc-patches]

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 use Unix style
>>> soname to mark when an ABI has changed.
>>
>> I tried generating the library as libgccjit-0.dll and naming its import 
>> library
>> libgccjit.dll.a. It worked. I understand you prefer the libgccjit-0.dll 
>> filename
>> from this comment about libtool. A patch implementing this change is 
>> attached.
>>
>> Thanks for your feedback.
>>
>> Nicolas.
>>
> 
> Thanks for the patch, it looks good to me. I will push this soon if no
> one else objects.
> 
> 

Thanks, pushed to git master.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Port libgccjit to Windows.

[JonY via Gcc-patches]

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 ABI has changed.
> 
> I tried generating the library as libgccjit-0.dll and naming its import 
> library
> libgccjit.dll.a. It worked. I understand you prefer the libgccjit-0.dll 
> filename
> from this comment about libtool. A patch implementing this change is attached.
> 
> Thanks for your feedback.
> 
> Nicolas.
> 

Thanks for the patch, it looks good to me. I will push this soon if no
one else objects.




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Port libgccjit to Windows.

[JonY via Gcc-patches]

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 Windows should use LIBGCCJIT_SONAME rather than
>> LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead
>> of libgccjit.so directly. The linker command output needs to be
>> LIBGCCJIT_SONAME.
> 
> Do you think the library should be called libgccjit.so.0 instead of the more
> Windows-like libgccjit.dll? That seems weird. Could you explain why?

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 ABI has changed.

Applications loading libgccjit.so.0 should be recompiled if a new
incompatible ABI libgccjit.so.1 is introduced. If a recompile is not
possible, the older library can still be installed side by side.

Applications should still link against the file generated import library
for transparency.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Port libgccjit to Windows.

[JonY via Gcc-patches]

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 "SECURITY_ATTRIBUTES" suggest to me that if
>>> lpSecurityDescriptor is NULL, then the directory gets a default
>>> security descriptor, and that this may mean it's only readable by
>> the
>>> user represented by the access token of the process [1], which
>> might
>>> suggest a simplification - but I'm very hazy on how the security
>> model
>>> in Windows works)
>>
>> I tested this and it gives write access to the "Authenticated Users"
>> group. 
> 
> Aha - sounds like that would be a problem.  Thanks for clarifying.
> 
>> The
>> way I did it gives access only to the user that owns the libgccjit
>> process. I
>> have to admit that it is a lot of code and it is hard to understand
>> unless you
>> know the security model of Windows well. I don't know it well, I
>> wrote this
>> keeping the documentation close and experimenting.
> 
> Thanks.
> 
>>> 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 your patch to master as
>>> c83027f32d9cca84959c7d6a1e519a0129731501.
>>>
>>> Thanks again for the patch
>>> Dave
>>
>> Thanks to you for all the good feedback.
>>
>> Nico.
> 

Hello,

A bit of a late review, some minor points:

1. Using .so on Windows for DLLs is fine.
2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than
LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead
of libgccjit.so directly. The linker command output needs to be
LIBGCCJIT_SONAME.
3. Ideally I would prefer to .cc too, though I see other C++ files also
written as .c.

Resend in case reply to list did not work,



signature.asc
Description: OpenPGP digital signature

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

[JonY via Gcc-patches]

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
>> ---
>>  gcc/config/i386/mingw32.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
>> index 1bbabfe8bed..321c30e41cc 100644
>> --- a/gcc/config/i386/mingw32.h
>> +++ b/gcc/config/i386/mingw32.h
>> @@ -165,7 +165,7 @@ along with GCC; see the file COPYING3.  If not see
>>  #define REAL_LIBGCC_SPEC \
>>"%{mthreads:-lmingwthrd} -lmingw32 \
>> " SHARED_LIBGCC_SPEC " \
>> -   -lmoldname -lmingwex -lmsvcrt"
>> +   -lmoldname -lmingwex -lmsvcrt -lkernel32"
>>   #undef STARTFILE_SPEC
>>  #define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
>>
> 
> This patch originates from this discussion on #mingw-w64 on OFTC:
> 
> ```
> [20:09:50]  there is suddenly an unexpected call to
> `IsDBCSLeadByteEx()` in winpthreads. Not sure why it gets involved.
> [20:13:12] * tchan (~tc...@c-98-220-238-152.hsd1.il.comcast.net) has joined
> [20:22:28]  diff'ing the import tables the previous working
> binary and now broken binary reveals that the old symbol to `printf` is
> gone. seems the mingw-w64 ones is called, which references
> `IsDBCSLeadByteEx()` and `WideCharToMultiByte()`.
> [20:27:19]  both of those should be provided by -lkernel32 right?
> [20:27:36] * Dejan has quit (Quit: Leaving)
> [20:34:09]  probably, but I doubt whether it should behave
> this way.  when perform cross-compilation the CRT is not available when
> building winpthreads.
> [20:34:37]  presumably it should always call the MS one.
> [20:34:45]  I'm pretty sure you'd first build the crt, then
> libraries like winpthreads - the other way around doesn't work
> [20:35:16]  :|  let me make a test program.
> [20:38:38]  can't reproduce it myself.
> [20:41:06]  there may be something wrong with the OP'
> [20:41:18]  's configuration.  Normally kernel32 is a default lib.
> [20:42:39]  I still think winpthreads should be built with
> `CPPFLAGS='-D__USE_MINGW_ANSI_STDIO=0'`. I built a local package and
> there is no reference to DBCS or wide char functions.
> [20:49:21]   reproduced now:
> https://paste.ubuntu.com/p/HwNk8WqgkD/
> [20:49:23]  Title: Ubuntu Pastebin (at paste.ubuntu.com)
> [20:52:45]  strange:  -lmingw32 -lgcc -lgcc_eh -lmoldname
> -lmingwex -lmsvcrt -lpthread -lmcfgthread -ladvapi32 -lshell32 -luser32
> -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt
> [20:53:10]  oh.
> [20:53:22]  the mingw-w64 `printf` is defined in mingwex I guess?
> [20:53:22]  pthread pulls in objects from msvcrt, which then needs
> things from kernel32, but there's no more kernel32 after msvcrt
> [20:54:04]  in 211af1e7d4d188dbefacea7af8b83d32b3edb48c I moved
> mbrtowc and wcrtomb from mingwex to msvcrt
> [20:54:37]  (but that wouldn't make a difference wrt this, as
> there's no kernel32 after the first mingwex after -lpthread either)
> [20:55:10]  I think it would be good with yet another -lkernel32
> after -lmsvcrt
> [20:55:27]  after all, that's the way they are layered anyway - the
> crt runs on top of kernel32
> [20:56:32]  and we want to have the freedom to have object file
> implementations in libmsvcrt.a
> [20:58:21]  some of these -l things are hard-coded in GCC
> default specs.
> [20:58:48]  I only found `-ladvapi32 -lshell32 -luser32
> -lkernel32`. The list ends there.
> [20:59:11]  not sure how those additional libraries were added.
> [21:00:04]  lld is nice in this aspect, that it doesn't need static
> libraries ordered like this; for each undefined, it searches the list of
> static libraries from the start
> [21:01:07]  LD is dumb. :(
> [21:02:53]  I thought MSVCRT was only an import library. It
> seems more complicated.
> [21:04:18]  it has (almost) always been more than that - there's
> been some stub functions that call GetProcAddress() and try to
> conditionally load functions if available
> [21:04:53]  and especially with ucrt, we want to move quite a bit
> of things from libmingwex.a to libmsvcrt-os.a, for things where we can
> and should use the ucrt equivalent instead of statically linking in our own
> [21:05:32]  GetProcAdress() requires a successive -lkernel32 too.
> [21:05:45]  indeed
> [21:06:56]  so this suddenly becomes a GCC issue in its
> default specs:  `-lkernel32` is required after `-lmsvcrt`.
> [21:07:33]  yes, pretty much. clang has got the same structure as well
> [21:07:44]  (which matters for cases when using clang on top of ld.bfd)
> [21:08:48]  looks like it's REAL_LIBGCC_SPEC in
> gcc/config/i386/mingw32.h that needs to be updated
> ```
> 
> 
> 

Thanks pushed to master.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Port libgccjit to Windows.

[JonY via Gcc-patches]

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 your patch to master as 
>>> c83027f32d9cca84959c7d6a1e519a0129731501.
>>> 
>>> Thanks again for the patch Dave
>> 
>> Thanks to you for all the good feedback.
>> 
>> Nico.
> 

Hello,

A bit of a late review, some minor points:

1. Using .so on Windows for DLLs is fine.
2. The DLL name on Windows should use LIBGCCJIT_SONAME rather than
LIBGCCJIT_LINKER_NAME, so applications would load libgccjit.so.0 instead
of libgccjit.so directly. The linker command output needs to be 
LIBGCCJIT_SONAME.
3. Ideally I would prefer to .cc too, though I see other C++ files also written 
as .c.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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
>>> (not preserved over calls), while in gcc they are currently handled as
>>> preserved across the calls.
> 
> The other parts are I guess mainly about SEH.  Consider e.g.
> void
> foo (void)
> {
>   register double x __asm ("xmm14");
>   register double y __asm ("xmm18");
>   asm ("" : "=x" (x));
>   asm ("" : "=v" (y));
>   x += y;
>   y += x;
>   asm ("" : : "x" (x));
>   asm ("" : : "v" (y));
> }
> looking at cross-compiler output, with -O2 -mavx512f this emits
>   .file   "abcdeq.c"
>   .text
>   .align 16
>   .globl  foo
>   .deffoo;.scl2;  .type   32; .endef
>   .seh_proc   foo
> foo:
>   subq$40, %rsp
>   .seh_stackalloc 40
>   vmovaps %xmm14, (%rsp)
>   .seh_savexmm%xmm14, 0
>   vmovaps %xmm18, 16(%rsp)
>   .seh_savexmm%xmm18, 16
>   .seh_endprologue
>   vaddsd  %xmm18, %xmm14, %xmm14
>   vaddsd  %xmm18, %xmm14, %xmm18
>   vmovaps (%rsp), %xmm14
>   vmovaps 16(%rsp), %xmm18
>   addq$40, %rsp
>   ret
>   .seh_endproc
>   .ident  "GCC: (GNU) 10.0.1 20200207 (experimental)"
> Does whatever assembler mingw64 uses even assemble this (I mean the
> .seh_savexmm %xmm16, 16 could be problematic)?''

It does not, I just checked with the master branch of binutils.

> I can find e.g.
> https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
> which then links to
> https://gcc.gnu.org/PR65782
> 
> So, I'd say we want to add PR target/65782 to the ChangeLog entry in the
> patch, and likely add a testcase like the above, so like below?
> 
> Have you tested the earlier version of the patch on mingw64 or cygwin?
> If yes, can you just test the testcase from the following patch, without and
> with the i386.h part and verify it FAILs without and PASSes with it?
> Just make check-gcc RUNTESTFLAGS=i386.exp=pr65782.c should do?
> If not, can you please test the whole patch?
> 

I did a -c test build with an older toolchain, it fails to compile
(invalid register for .seh_savexmm) while the latest gcc is passing,
both are using the same binutils version.

I guess that covers it?


> 2020-02-07  Uroš Bizjak  
>   Jakub Jelinek  
> 
>   PR target/65782
>   * config/i386/config/i386/i386.h (CALL_USED_REGISTERS): Make
>   xmm16-xmm31 call-used even in 64-bit ms-abi.
> 
>   * gcc.target/i386/pr65782.c: New test.
> 
> --- gcc/config/i386/config/i386/i386.h.jj 2020-01-22 10:19:24.199221986 
> +0100
> +++ gcc/config/i386/config/i386/i386.h2020-02-04 12:09:12.338341003 
> +0100
> @@ -1128,9 +1128,9 @@ extern const char *host_detect_local_cpu
>  /*xmm8,xmm9,xmm10,xmm11,xmm12,xmm13,xmm14,xmm15*/\
>   6,   6,6,6,6,6,6,6, \
>  /*xmm16,xmm17,xmm18,xmm19,xmm20,xmm21,xmm22,xmm23*/  \
> - 6,6, 6,6,6,6,6,6,   \
> + 1,1, 1,1,1,1,1,1,   \
>  /*xmm24,xmm25,xmm26,xmm27,xmm28,xmm29,xmm30,xmm31*/  \
> - 6,6, 6,6,6,6,6,6,   \
> + 1,1, 1,1,1,1,1,1,   \
>   /* k0,  k1,  k2,  k3,  k4,  k5,  k6,  k7*/  \
>   1,   1,   1,   1,   1,   1,   1,   1 }
>  
> --- gcc/testsuite/gcc.target/i386/pr65782.c.jj2020-02-07 
> 12:21:09.472819018 +0100
> +++ gcc/testsuite/gcc.target/i386/pr65782.c   2020-02-07 12:24:06.820154495 
> +0100
> @@ -0,0 +1,16 @@
> +/* PR target/65782 */
> +/* { dg-do assemble { target { avx512vl && { ! ia32 } } } } */
> +/* { dg-options "-O2 -mavx512vl" } */
> +
> +void
> +foo (void)
> +{
> +  register double x __asm ("xmm14");
> +  register double y __asm ("xmm18");
> +  asm ("" : "=x" (x));
> +  asm ("" : "=v" (y));
> +  x += y;
> +  y += x;
> +  asm ("" : : "x" (x));
> +  asm ("" : : "v" (y));
> +}
> 
> 
>   Jakub
> 




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 #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.
>>>
>>> I don't have means of testing it either.
>>> https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
>>> is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15 (low
>>> 128-bits only) are call preserved.
>>>
>>> Jonathan, could you please test this if it is sufficient to just change
>>> CALL_USED_REGISTERS or if e.g. something in the pro/epilogue needs tweaking
>>> too?  Thanks.
>>
>> 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
> (not preserved over calls), while in gcc they are currently handled as
> preserved across the calls.
> 
>   Jakub
> 


--- original.s  2020-02-06 09:00:02.014638069 +
+++ new.s   2020-02-07 10:28:55.678317667 +
@@ -7,23 +7,23 @@
 qux:
subq$72, %rsp
.seh_stackalloc 72
-   vmovaps %xmm18, 48(%rsp)
-   .seh_savexmm%xmm18, 48
+   vmovaps %xmm6, 48(%rsp)
+   .seh_savexmm%xmm6, 48
.seh_endprologue
callbar
vmovapd %xmm0, %xmm1
-   vmovapd %xmm1, %xmm18
+   vmovapd %xmm1, %xmm6
callfoo
leaq32(%rsp), %rcx
-   vmovapd %xmm18, %xmm0
-   vmovaps %xmm0, 32(%rsp)
+   vmovapd %xmm6, %xmm0
+   vmovapd %xmm0, 32(%rsp)
callbaz
nop
-   vmovaps 48(%rsp), %xmm18
+   vmovaps 48(%rsp), %xmm6
addq$72, %rsp
ret
.seh_endproc
-   .ident  "GCC: (GNU) 10.0.0 20191024 (experimental)"
+   .ident  "GCC: (GNU) 10.0.1 20200206 (experimental)"
.defbar;.scl2;  .type   32; .endef
.deffoo;.scl2;  .type   32; .endef
.defbaz;.scl2;  .type   32; .endef

GCC with the patch now seems to put the variables in xmm6, unfortunately
I don't know enough of AVX or stack setups to know if that's all that is
needed.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
>>> -Wno-unused-variable -Wno-unused-parameter
>>> -Wno-unused-but-set-variable -Wno-uninitialized -O0
>>> -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
>>> FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
>>> -Wno-unused-variable -Wno-unused-parameter
>>> -Wno-unused-but-set-variable -Wno-uninitialized -O2
>>> -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
>>> FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55
>>> -Wno-unused-variable -Wno-unused-parameter
>>> -Wno-unused-but-set-variable -Wno-uninitialized -O0
>>> -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
>>> FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=55
>>> -Wno-unused-variable -Wno-unused-parameter
>>> -Wno-unused-but-set-variable -Wno-uninitialized -O2
>>> -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
>>> FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56
>>> -Wno-unused-variable -Wno-unused-parameter
>>> -Wno-unused-but-set-variable -Wno-uninitialized -O0
>>> -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
>>> FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=56
>>> -Wno-unused-variable -Wno-unused-parameter
>>> -Wno-unused-but-set-variable -Wno-uninitialized -O2
>>> -DABI_NUM=FFI_GNUW64 -DABI_ATTR=MSABI execution test
>>>
>>> in libffi testsuite.
>>>
>>> OK for master and backports to GCC 8/9 branches?
>>>
>>> gcc/
>>>
>>> PR target/85667
>>> * config/i386/i386.c (function_arg_ms_64): Add a type argument.
>>> Don't return aggregates with only SFmode and DFmode in SSE
>>> register.
>>> (ix86_function_arg): Pass arg.type to function_arg_ms_64.
>>>
>>> gcc/testsuite/
>>>
>>> PR target/85667
>>> * gcc.target/i386/pr85667-10.c: New test.
>>> * gcc.target/i386/pr85667-7.c: Likewise.
>>> * gcc.target/i386/pr85667-8.c: Likewise.
>>> * gcc.target/i386/pr85667-9.c: Likewise.
>>
>> LGTM, but should really be reviewed by cygwin, mingw-w64 maintainer (CC'd).
>>
> 
> I checked the result against MSVC v19.10 at
> 
> https://godbolt.org/z/2NPygd
> 
> My patch matches MSVC v19.10.  I am checking it in tomorrow unless
> mingw-w64 maintainer objects.
> 

Please go ahead and thanks.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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.
> 
> I don't have means of testing it either.
> https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
> is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15 (low
> 128-bits only) are call preserved.
> 
> Jonathan, could you please test this if it is sufficient to just change
> CALL_USED_REGISTERS or if e.g. something in the pro/epilogue needs tweaking
> too?  Thanks.

Is this patch testing still required? I just got back from traveling.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 deleted due to some
> handles left open.
> 
> 
>>> This could also mean that there is no effect way to denote a thread
>>> uniquely. As a consequence libstdc++ may have to its own bookkeeping
>>> mechanism.
>>
>> As I said in my last mail, libstdc++ does not need a way to denote a
>> thread uniquely.
>>
> 
> At my last glance at the `__gthread_` interfaces, libstdc++ requires
> thread IDs to be LessThanComparable, which would require retrieval of
> thread IDs by handle, as in `__gthread_equal()`.
> 
> More than that, if my previous vision was correct (a terminated thread
> has no ID associated) then `GetThreadId()` on a thread that has
> terminated would not return a valid thread ID. Fortunately, this seems
> not the case:
> 
> ```c
> #include 
> #include 
> 
> DWORD __stdcall ThreadProc(void* pParam)
>   {
> printf("thread %lu running\n", GetCurrentThreadId());
> return 0;
>   }
> 
> int main(void)
>   {
> HANDLE hThread = CreateThread(0, 0, ThreadProc, 0, CREATE_SUSPENDED, 0);
> printf("thread %lu created\n", GetThreadId(hThread));
> 
> ResumeThread(hThread);
> WaitForSingleObject(hThread, INFINITE);
> printf("thread %lu terminated\n", GetThreadId(hThread));
> 
> CloseHandle(hThread);
> // `hThread` is now invalid; DO NOT PLAY WITH THIS AT HOME!
> printf("thread %lu closed\n", GetThreadId(hThread));
>   }
> ```
> 
> This program outputs
> 
> ```text
> E:\Desktop>gcc test.c -Wall -Wextra -Wpedantic && a.exe
> test.c: In function 'ThreadProc':
> test.c:4:34: warning: unused parameter 'pParam' [-Wunused-parameter]
> 4 | DWORD __stdcall ThreadProc(void* pParam)
>   |~~^~
> thread 9172 created
> thread 9172 running
> thread 9172 terminated
> thread 0 closed
> 
> E:\Desktop>
> ```
> 
> Despite Microsoft's documentation, the identifier of a thread seems
> uncollected as long as there are still handles to the thread. So it
> might be safe to assume that the identifier of an `std::thread` *cannot*
> be reused before it is `join()`'d or `detach()`'d which closes the
> handle stored in the `std::thread` object.
> 
> 

Any updates?



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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).
>> However, we now compile most sources with the C++ compiler and
>> the __USE_MINGW_ACCESS in CFLAGS is not used there. This causes
>> GCCs build against newer msvcrt versions with incompatible
>> access implementations to fail. This patch adds the flag to the
>> CXXFLAGS for all bootstrap stages. Bootstrapped on
>> x86_64-mingw64-seh.
>>
>> config/ChangeLog:
>>
>> 2019-03-02  Johannes Pfau  
>>
>>  * mh-mingw: Also set __USE_MINGW_ACCESS flag for C++ code.
>>
>> ---
>>  config/mh-mingw | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/config/mh-mingw b/config/mh-mingw
>> index bc1d27477d0..a795096f038 100644
>> --- a/config/mh-mingw
>> +++ b/config/mh-mingw
>> @@ -2,6 +2,11 @@
>>  # Vista (see PR33281 for details).
>>  BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
>>  CFLAGS += -D__USE_MINGW_ACCESS
>> +STAGE1_CXXFLAGS += -D__USE_MINGW_ACCESS
>> +STAGE2_CXXFLAGS += -D__USE_MINGW_ACCESS
>> +STAGE3_CXXFLAGS += -D__USE_MINGW_ACCESS
>> +STAGE4_CXXFLAGS += -D__USE_MINGW_ACCESS
>> +
>>  # Increase stack limit to a figure based on the Linux default, with 4MB 
>> added
>>  # as GCC turns out to need that much more to pass all the limits-* tests.
>>  LDFLAGS += -Wl,--stack,12582912
>>
> 
> Patch looks good, will apply soon.
> 

Forgot to reply that this was checked in as r269784.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 and
> the __USE_MINGW_ACCESS in CFLAGS is not used there. This causes
> GCCs build against newer msvcrt versions with incompatible
> access implementations to fail. This patch adds the flag to the
> CXXFLAGS for all bootstrap stages. Bootstrapped on
> x86_64-mingw64-seh.
> 
> config/ChangeLog:
> 
> 2019-03-02  Johannes Pfau  
> 
>   * mh-mingw: Also set __USE_MINGW_ACCESS flag for C++ code.
> 
> ---
>  config/mh-mingw | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/config/mh-mingw b/config/mh-mingw
> index bc1d27477d0..a795096f038 100644
> --- a/config/mh-mingw
> +++ b/config/mh-mingw
> @@ -2,6 +2,11 @@
>  # Vista (see PR33281 for details).
>  BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
>  CFLAGS += -D__USE_MINGW_ACCESS
> +STAGE1_CXXFLAGS += -D__USE_MINGW_ACCESS
> +STAGE2_CXXFLAGS += -D__USE_MINGW_ACCESS
> +STAGE3_CXXFLAGS += -D__USE_MINGW_ACCESS
> +STAGE4_CXXFLAGS += -D__USE_MINGW_ACCESS
> +
>  # Increase stack limit to a figure based on the Linux default, with 4MB added
>  # as GCC turns out to need that much more to pass all the limits-* tests.
>  LDFLAGS += -Wl,--stack,12582912
> 

Patch looks good, will apply soon.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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, 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.
>>>>> Please let me know your thoughts/suggestions.
>>>>
>>>> ChangeLog entry is missing, please write it (and mention there
>>>> Mateusz's name/mail as he wrote the i386.c part).
>>>>
>>
>> Patch looks good to me, but please add a ChangeLog.
>>
>>
> 
> 

Changelog OK too.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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.
>>> Please let me know your thoughts/suggestions.
>>
>> ChangeLog entry is missing, please write it (and mention there
>> Mateusz's name/mail as he wrote the i386.c part).
>>

Patch looks good to me, but please add a ChangeLog.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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!
> 
>> I now understand the problem, thanks for the clarification about the
>> patch. Patch is OK.
> 
> Thanks, here's what I'm installing (with comments indicating which
> configuration each setting applies to, and why one of them won't work)
> 
> 
> large-addr-aware for biarch non-w64 mingw32
> 
> for  gcc/ChangeLog
> 
>   * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Adjust
> for non-w64 x86_64 biarch.


This patch is certainly better with the explanation, OK for trunk.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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:
>>>> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option
>>>> '--large-address-aware'
>>>
>>> What does?  The patch I suggested?  The current trunk?
>>>
>>> What was the command in this case?  How was the toolchain configured?
> 
>> No it's just a quick test to see how x86_64-w64-mingw32 reacts to
>> --large-address-aware, it doesn't play well.
> 
> I understand, but you're getting a different result from what I am, I'd
> like to understand why before attempting to "fix" something that AFAICT
> is correct and behaving just as intended.  Maybe there are valid reasons
> to drop --large-address-aware altogether on x86_64-w64-mingw32, but I'd
> like to understand why, as in, how the error above came about for you,
> when it didn't for me.
> 
> I built gcc and binutils in a single tree, with x86_64-w64-mingw32 as
> the target, and the resulting linker would accept --large-address-aware
> in the -mi386-pe emulation, and that emulation was explicitly enabled
> when building -m32 binaries.  Does your w64 toolchain deviate from any
> of these facts?
> 

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.

> 
>> x86_64-mingw32 is not used as far as I know, only with "w64" or "pc".
> 
> x86_64-mingw32's canonical form is x86_64-pc-mingw32, and they're
> equivalent, so whatever you say or know about the latter should apply to
> the shorter form as well.  Likewise, my questions and doubts about the
> shorter form apply equally to the canonical one.
> 
>> The "w64" carries a special meaning to gcc dating back to the early
>> 64bit port. It basically tells gcc to use mingw-w64 specific features
>> that are not found on the regular mingw.org CRT at the time.
> 
> I see.  So -pc- and -w64- are not supposed to be equivalent indeed.
> Thanks.
> 
>> This might be affecting the "pc" vendor build, can you check
>> x86_64-pc-mingw32 just to see if it is affected?
> 
> I did.  Its -m32 mode seems broken to me.  As I wrote, the linker
> emulation is never specified, so it would build 64-bit binaries even
> when given -m32.  Because it lacks explicit linker emulation
> specification, it can't have --large-address-aware specified either.
> 
> In my link tests, i686-mingw32 and x86_64-w64-mingw32 both worked (in
> that their respective linkers wouldn't reject the --large-address-aware
> passed by gcc) with the --large-address-aware patch that is installed in
> trunk.  Ditto with the incremental patch I posted last week, that would
> have only improved x86_64-pc-mingw32.
> 

I now understand the problem, thanks for the clarification about the
patch. Patch is OK.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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?  The current trunk?
> 
> What was the command in this case?  How was the toolchain configured?
> 
> 
> I've been looking into this, getting progressively puzzled, though I
> actually managed to duplicated the problem you mentioned, but only on
> x86_64-mingw32, NOT on x86_64-w64-mingw32.
> 
> 

No it's just a quick test to see how x86_64-w64-mingw32 reacts to
--large-address-aware, it doesn't play well.

> Here's what I found out in my investigation:
> 
> configured for i686-mingw32, GNU ld supports only the i386pe emulation,
> that supports the --large-address-aware flag.
> 
> Configured for x86_64-*-mingw32, it supports i386pe, but it defaults to
> i386pep, the 64-bit binary format, that does NOT support
> --large-address-aware.
> 
> x86_64-w64-mingw32 passes -mi386pe or -mi386pep to the linker, depending
> on -m32 or -m64, so the code to pass --large-address-aware to link -m32
> binaries in mingw-w64.h looks correct to me.  But x86_64-mingw32 does
> NOT use that: it uses the LINK_SPEC from mingw32.h, so it doesn't
> specify the emulation, ever.  That seems awfully broken to me.  If you
> ask for a 32-bit binary, using the default 64-bit linker format is
> unlikely to produce the desired results.
> 
> Is x86_64-mingw32 really supposed to be a usable target name?  It might
> even work as a 64-bit only target, but I don't see how its biarch
> support could possibly be functional.
> 
> If it is to be usable, is it really supposed to be different from
> x86_64-w64-mingw32?  Using mingw-w64.h besides mingw32.h would fix the
> biarch problems, but perhaps that's not desired for other reasons.
> 
> Fixing that is way beyond my knowledge or interest on Windows-based
> platforms, but given clarification as to whether x86_64-mingw32 is
> supposed to support biarch at all, I might be able to fix the
> implementation of --enable-large-address-aware there.
> 
> As for the problem you reported on x86_64-w64-mingw32, I'm afraid I'll
> need some more information to be able to duplicate that and try to fix
> it.
> 
> Thanks,
> 

x86_64-mingw32 is not used as far as I know, only with "w64" or "pc".

The "w64" carries a special meaning to gcc dating back to the early
64bit port. It basically tells gcc to use mingw-w64 specific features
that are not found on the regular mingw.org CRT at the time.

This might be affecting the "pc" vendor build, can you check
x86_64-pc-mingw32 just to see if it is affected?

Thanks.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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.
> ^ s/2/w/, fixing...
> 
> Now, it occurred to me that it is possible for biarch64.h to be
> included, thus enabling 64-bit mode even by default, without including
> mingw-w64.h.  I had assumed in my patch that this was not supposed to
> happen, but configuring with --target=x86_64-mingw32 shows it does
> happen, and such a toolchain may (after my patch) pass
> --large-address-aware to the linker, even when linking -m64 binaries.
> 
> Is that target configuration really supposed to be different from
> x86_64-w64-mingw32 (or however else the w64 configuration is supposed to
> be spelled), or should x86_64-mingw32 also use mingw-w64.h so that
> they're equivalent?
> 
> It seems to me that we need a further patch like this:
> 
> diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
> index c9d8a7a31f30..848eb8430b30 100644
> --- a/gcc/config/i386/mingw32.h
> +++ b/gcc/config/i386/mingw32.h
> @@ -114,11 +114,17 @@ along with GCC; see the file COPYING3.  If not see
>  #define SUBTARGET_EXTRA_SPECS
> \
>{ "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC }
>  
> -#if MINGW_DEFAULT_LARGE_ADDR_AWARE
> +#if ! MINGW_DEFAULT_LARGE_ADDR_AWARE
> +# define LINK_SPEC_LARGE_ADDR_AWARE ""
> +#elif ! TARGET_BI_ARCH
>  # define LINK_SPEC_LARGE_ADDR_AWARE \
>"%{!shared:%{!mdll:--large-address-aware}}"
> +#elif TARGET_64BIT_DEFAULT
> +# define LINK_SPEC_LARGE_ADDR_AWARE \
> +  "%{!shared:%{!mdll:%{m32:--large-address-aware}}}"
>  #else
> -# define LINK_SPEC_LARGE_ADDR_AWARE ""
> +# define LINK_SPEC_LARGE_ADDR_AWARE \
> +  "%{!shared:%{!mdll:%{!m64:--large-address-aware}}}"
>  #endif
>  
>  #define LINK_SPEC "%{mwindows:--subsystem windows} \
> 
> But then, even this wouldn't necessarily do the right thing if e.g.
> biarchx32.h is in effect.  Is that even possible?
> 
> Or can we just leave mingw32.h as is, considering that (AFAIK) -m64 *is*
> --large-address-aware, it just has that enabled by default?
> 

Looks like it causes an error on 64bit:
/usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option
'--large-address-aware'

So it'll need to be excluded for x86_64.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 drop mingw from the name and make it default to
>>> enabled for cygwin.
> 
>> It is already enabled for Cygwin,
> 
> plus, I have no evidence that Cygwin even works without
> --large-address-aware, and I have no way to test that.
> 
>> but good point,
>> --enable-large-address-aware it is, but enabled only for mingw for now,
>> as such in the original patch.
> 
> Here's the patch, adjusted as requested and retested.  Ok to install?
> 
> 
> introduce --enable-large-address-aware
> 
> From: Alexandre Oliva 
> 
> 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.
> 
> for  gcc/ChangeLog
> 
>   * configure.ac: Introduce --enable-large-address-aware
>   to define MINGW_DEFAULT_LARGE_ADDR_AWARE.
>   * doc/install.texi: Document it.
>   * configure, config.in: Rebuilt.
>   * 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.

Patch looks OK to be.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 is, but enabled only for mingw for now,
as such in the original patch.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 as well, I could implement that,
>>> and drop -mingw from the option name.  I'd retain the current defaults
>>> of each target, unless there's a strong reason to change them.
> 
>> In that case, no objections then.
> 
> Thanks.  Now, before I proceed, please clarify: did you mean you had no
> objections to the patch I last proposed, or to the plan in my last
> paragraph above?
> 

Your last proposed plan to use --enable-mingw-large-address-aware to
affect only mingw. If there are more targets in the future that need
this, we can always drop the mingw part in the configure option.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 for Cygwin.
> 
> Cygwin already has --large-address-aware enabled, without an option to
> disable it.  That makes sense, considering that Cygwin targets Unix
> programs, unlikely to have Windows-specific pointer assumptions.
> 
> That's why I phrased the option, and implemented it, as specific to
> mingw.
> 
> Now, if you wish it to affect Cygwin as well, I could implement that,
> and drop -mingw from the option name.  I'd retain the current defaults
> of each target, unless there's a strong reason to change them.
> 

In that case, no objections then.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 both OK as far as I can see. I just don't like the configure
>> name implying all 32bit pointers are used by userspace. Perhaps just
>> --enable-large-address-aware?
> 
> That might suggest the flag affects all targets, including Cygwin, so
> I'm following the existing (undocumented) practice in suggesting
> --enable-mingw-large-address-aware instead.  Please let me know if you'd
> rather not have mingw in the option name, and for it to affect (in the
> --disable form) the Cygwin target as well.
> 

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 for Cygwin.

I don't think mingw should be in the configure name as this is
applicable to all Win32 PE targets, it is a PE flag after all.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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-mingw32-gcc and
> x86_64-w64-mingw64-gcc (is this the usual triplet name?), observing the
> flags passed by gcc to the linker when asked to create an executable
> program or a dynamic library, in 32- or, with the latter compiler, in
> 64-bit mode.
> 
> 
> I wonder if it makes any sense to extend/rename the configure flag to
> apply to cygwin as well, though it should default to enabled for that
> platform.
> 
> I also wonder if it makes sense, at this point, for mingw to default to
> --large-address-aware (I guess not, but it doesn't hurt to ask, does it?
> :-)
> 
> Yet another idea that comes to mind is to introduce gcc flags, say
> -m32full and -m31, to imply -m32 and also pass either
> --large-address-aware or --disable-large-address-aware, respectively, to
> the linker.
> 
> I suppose it might also make sense to approach this issue from the
> linker, rather than from GCC, enabling its default to be configured.
> Would that be preferred?  I thought tweaking GCC would be better, for
> the flag would be visible with -v, both the one passed to the linker and
> the one passed to GCC configure.  It wouldn't be quite as visible as a
> linker configuration knob.
> 
> 
> Given all this, is this patch below ok to install, or should I make
> changes.  I've included the configure and config.in changes because
> they're small enough.
> 
> Below this first patch, I enclose another patch for cygming.h.
> 

They're both OK as far as I can see. I just don't like the configure
name implying all 32bit pointers are used by userspace. Perhaps just
--enable-large-address-aware?

Be sure to also update the documentation as Joseph says.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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't
>> put irrelevant declarations between them.
> 
> You're probably right.  I'm guessing this bug was found because:
> 
>    int bob : 1;
>    int get_bob () const {return bob;}
>    void set_bob (bool v) {bob=v;}
>    int bill : 1;
>    ...
> 
> might be a useful style.
> 
>> An important reason why such code could be rare is that the following
>> code compiles differently as C and C++:
> 
>> struct foo
>>    {
>>  unsigned a : 21;
>>  union x1 { char x; };
>>  unsigned b : 11;
>>  union x1 u;
>>    };
> 
> (for C++) this happens to be a case we already get right.   I
> think that'd be a C vendor extension, I don't think unnamed fields are
> permitted there?
> 
> Here's a version of the patch to completely resolve the issue, tested on
> trunk.  I noticed regular x86 targets support the ms_struct attribute,
> so we can give this wider testing.  I did consider trying to reorder the
> field decls before struct layour, but that seemed a more invasive change
> -- besides it might be nice to be able to remove the template-specific
> CLASSTYPE_DECL_LIST which almost but not quite mirrors TYPE_FIELDS.
> 
> Ok for trunk, ok for 8?
> 
> nathan

I don't have any objections.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 these two patches, in this order:
> 
> 
> 
> * gcc/pretty-print.c (mingw_ansi_fputs): Do not call _close() on the handle
> returned by _get_osf_handle().
> 
> 
> 
> * gcc/pretty-print.c (eat_esc_sequence): Swap the foreground and background
> colors if the COMMON_LVB_REVERSE_VIDEO flag is set, and clear it
> thereafter,
> as it only works for DBCS.
> 
> 
> 

Patch and log looks OK.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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
>> asynchronous I/O, it is still necessary to link against libpthread,
>> libgomp or another library linked against any of the aforementioned two.
>> While it might not be the nicest way, it at least keeps in line with the
>> likes of ifort. Two of the test I send deal with asynchronous error
>> handling, so they will fail if not linked accordingly.
>>
>> Since the implementation relies on pthreads, it would be great if
>> somebody could try the patch on non-linux targets, to see whether it
>> causes any problems there.
>>
>> Let the rain of regressions begin ;)
>>
>> Nicolas
>>
>> P.S.: I would very much recommend removing the #undef DEBUG in async.h.
>> I have to admit, I am quite proud of the debug printouts. They even
>> build a data structure in the background telling you were a locked mutex
>> was locked.
> 
> I'm not too familiar with Fortran, but I'll test it out over the
> weekends with the asynchronous_9.f90 program.
> 
> 

Looks like v1 is working with x86_64-w64-mingw32 and winpthreads, I
don't have the mail for v2, strangely.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 another library linked against any of the aforementioned two.
> While it might not be the nicest way, it at least keeps in line with the
> likes of ifort. Two of the test I send deal with asynchronous error
> handling, so they will fail if not linked accordingly.
> 
> Since the implementation relies on pthreads, it would be great if
> somebody could try the patch on non-linux targets, to see whether it
> causes any problems there.
> 
> Let the rain of regressions begin ;)
> 
> Nicolas
> 
> P.S.: I would very much recommend removing the #undef DEBUG in async.h.
> I have to admit, I am quite proud of the debug printouts. They even
> build a data structure in the background telling you were a locked mutex
> was locked.

I'm not too familiar with Fortran, but I'll test it out over the
weekends with the asynchronous_9.f90 program.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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
> revamp from Eric and follow-up fix r114552, the rest has been introduced
> later when the known_align < desired_align case has been enabled for the ms
> bitfield layout.
> 
> The first 2 hunks fix alignment of packed non-bitfield fields, we can't
> ignore all the alignment updates for them, just should use only
> desired_align which takes DECL_PACKED into account, rather than
> MAX (type_align, desired_align).  Similarly, the last hunk in stor-layout.c
> makes sure that for DECL_PACKED fields we use BITS_PER_UNIT alignment rather
> than the type alignment.
> 
> The rest attempts to unbreak r184409 which enabled known_align < desired_align
> case; doing that if rli->prev_field and ms layout is wrong, we first need to
> deal with the bitfield packing and if we are within a bitfield word, we
> shouldn't do any realignment, only in between them.
> 
> The patch reverts changes to bf-ms-layout{,-2}.c tests done in 2012, which
> were done just to match the r184409 changes, and adds 2 new tests.  All of
> these 4 I've tested (slightly tweaked, so that it compiles with VC) with
> the online VC compiler http://rextester.com/l/c_online_compiler_visual .
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 

No objections.





signature.asc
Description: OpenPGP digital signature

Re: [PING] Plugin support on Windows/MinGW

[JonY]

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 haven't tested it. The problem with using .so instead
>> of .dll is that producing this non-standard extension may not be easy
>> or possible depending on the build system/tool (e.g., libtool). Also,
>> you never know how other pieces of the system (like antivirus) will
>> react to a file that looks like a DLL but is called something else.
>>
>>
> 
> Libtool shouldn't matter since it is not used to build those, and I
> doubt AVs would care what the filename is called. Apache on Windows uses
> .so plugins too.
> 
>>> ... if it simplifies the code?
>>
>> I don't think it simplifies that much and the potential (and unknown)
>> downside is significant.
>>
>> Thanks for the review,
>> Boris
>>
> 
> I'll commit in a few days if there are no more inputs.
> 

Applied to trunk r255154.



signature.asc
Description: OpenPGP digital signature

Re: [PING] Plugin support on Windows/MinGW

[JonY]

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
> of .dll is that producing this non-standard extension may not be easy
> or possible depending on the build system/tool (e.g., libtool). Also,
> you never know how other pieces of the system (like antivirus) will
> react to a file that looks like a DLL but is called something else.
> 
> 

Libtool shouldn't matter since it is not used to build those, and I
doubt AVs would care what the filename is called. Apache on Windows uses
.so plugins too.

>> ... if it simplifies the code?
> 
> I don't think it simplifies that much and the potential (and unknown)
> downside is significant.
> 
> Thanks for the review,
> Boris
> 

I'll commit in a few days if there are no more inputs.



signature.asc
Description: OpenPGP digital signature

Re: [PING] Plugin support on Windows/MinGW

[JonY]

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
> by default (there are also fixes for a couple of bugs as a bonus).
> I would really liked to have this patch considered for GCC 8, if
> possible.
> 
> Thanks,
> Boris
> 

Is there a problem with using .so for internal libraries instead of
"dll" if it simplifies the code?

I don't see any other problems with it.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH][mingw] Enable colorized diagnostics

[JonY]

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
>> this feature, I suppose it is OK.
>>
>> I will commit soon if there are no more comments.
>>
>>
> 
> Thank you. By the way I noticed a mistake in the comments above
> `find_esc_terminator()`. This function returns zero on failure like its
> `find_esc_head()` counterpart, while the comments mistakenly referred
> -1. Please correct it before committing.
> 
> 

Committed to trunk r253645 with the appropriate change.



signature.asc
Description: OpenPGP digital signature

Re: [PATCH][mingw] Enable colorized diagnostics

[JonY]

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 MinGW host, and nothing to do with the
>> target.
>>
> Ping? Are there any more opinions about this?
> 

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
this feature, I suppose it is OK.

I will commit soon if there are no more comments.




signature.asc
Description: OpenPGP digital signature

Re: [PATCH][mingw] Enable colorized diagnostics

[JonY]

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 MinGW host, and nothing to do with the
>> target.
>>
> Oh you are right. Since I build native compilers, host == target here.
> But strictly speaking the patch applies to the host, not the target.
> 

Does it make sense to use a global lock in mingw_ansi_fputs?



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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: Regenerated.
>   * Makefile.in: Regenerated.
>   * testsuite/Makefile.in: Regenerated.
> 
> 
> Index: configure.ac
> ===
> --- configure.ac  (revision 250986)
> +++ configure.ac  (working copy)
> @@ -147,6 +147,7 @@
>  
>  # Configure libtool
>  AM_PROG_LIBTOOL
> +ACX_LT_HOST_FLAGS
>  AC_SUBST(enable_shared)
>  AC_SUBST(enable_static)
>  
> Index: Makefile.am
> ===
> --- Makefile.am   (revision 250986)
> +++ Makefile.am   (working copy)
> @@ -54,7 +54,7 @@
>  # want or need libstdc++.
>  libitm_la_DEPENDENCIES = $(libitm_version_dep)
>  libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
> -libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)
> +libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script) 
> $(lt_host_flags)
>  
>  libitm_la_SOURCES = \
>   aatree.cc alloc.cc alloc_c.cc alloc_cpp.cc barrier.cc beginend.cc \
> 

Ping.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 with my other patches.  OK for trunk?
>>
>> * config/i386/i386-opts.h (enum calling_abi): Modify so that no legal
>> values are equivalent to zero.
> 
> Please add UNKNOWN_ABI to the enum and initialize -mabi in i386.opt to
> UNKNOWN_ABI.
> 
> Then change the above condition to
> 
> if (opts_set->x_ix86_abi == UNKNOWN_ABI)
> 
> We can't just init -mabi to DEFAULT_ABI, sinde this is selected at
> runtime. Maybe a comment should be added for UNKNOWN_ABI, that it is
> overriden in ix86_option_override_internal.
> 
> Uros.

This sounds sensible if there was ever a time some new ABI is added for x86.



signature.asc
Description: OpenPGP digital signature

[PATCH] Enable libitm DLL build on Cygwin/Mingw

[JonY]

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: Regenerated.


Index: configure.ac
===
--- configure.ac(revision 250986)
+++ configure.ac(working copy)
@@ -147,6 +147,7 @@
 
 # Configure libtool
 AM_PROG_LIBTOOL
+ACX_LT_HOST_FLAGS
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)
 
Index: Makefile.am
===
--- Makefile.am (revision 250986)
+++ Makefile.am (working copy)
@@ -54,7 +54,7 @@
 # want or need libstdc++.
 libitm_la_DEPENDENCIES = $(libitm_version_dep)
 libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
-libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)
+libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script) 
$(lt_host_flags)
 
 libitm_la_SOURCES = \
aatree.cc alloc.cc alloc_c.cc alloc_cpp.cc barrier.cc beginend.cc \



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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_EXECUTE_STACK_ENABLED
* libgcc/config.host (*-cygwin): Include file from mingw
config/i386/enable-execute-stack-mingw32.c

--
Index: gcc/config/i386/cygming.opt
===
--- gcc/config/i386/cygming.opt (revision 250913)
+++ gcc/config/i386/cygming.opt (working copy)
@@ -50,6 +50,10 @@
 Target Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)})
 Compile code that relies on Cygwin DLL wrappers to support C++ operator
new/delete replacement.

+fset-stack-executable
+Common Report Var(flag_setstackexecutable) Init(1) Optimization
+For nested functions on stack executable permission is set.
+
 posix
 Driver

Index: gcc/config/i386/cygwin.h
===
--- gcc/config/i386/cygwin.h(revision 250913)
+++ gcc/config/i386/cygwin.h(working copy)
@@ -153,3 +153,7 @@
 #endif
 #define LIBGCC_SONAME "cyggcc_s" LIBGCC_EH_EXTN "-1.dll"

+/* Make stack executable to avoid DEP problems with trampolines.  */
+#define HAVE_ENABLE_EXECUTE_STACK
+#undef  CHECK_EXECUTE_STACK_ENABLED
+#define CHECK_EXECUTE_STACK_ENABLED flag_setstackexecutable
Index: gcc/config/i386/mingw.opt
===
--- gcc/config/i386/mingw.opt   (revision 250913)
+++ gcc/config/i386/mingw.opt   (working copy)
@@ -28,8 +28,4 @@
 C ObjC C++ ObjC++ Var(warn_pedantic_ms_format) Init(1) Warning
 Warn about none ISO msvcrt scanf/printf width extensions.

-fset-stack-executable
-Common Report Var(flag_setstackexecutable) Init(1) Optimization
-For nested functions on stack executable permission is set.
-
 ; Need to retain blank line above.
Index: libgcc/config.host
===
--- libgcc/config.host  (revision 250913)
+++ libgcc/config.host  (working copy)
@@ -324,6 +324,9 @@
 i[34567]86-*-mingw* | x86_64-*-mingw*)
   enable_execute_stack=config/i386/enable-execute-stack-mingw32.c
   ;;
+i[34567]86-*-cygwin* | x86_64-*-cygwin*)
+  enable_execute_stack=config/i386/enable-execute-stack-mingw32.c
+  ;;
 *)
   enable_execute_stack=enable-execute-stack-empty.c;
   ;;



signature.asc
Description: OpenPGP digital signature

Re: Deprecate DBX/stabs?

[JonY]

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 (thus both -g and -gstabs
> will warn).  On systems where stabs is not preferred, -gstabs will not
> give you a warning.  The patch survices an x86_64-linux bootstrap.
> 
> A config can chose to override thus by defining 'DBX_DEBUG_OK' in the
> build defines.
> 
> I did try build time CPP tricks, but config/rx.h and
> config/i386/darwin.h define it to be a conditional expression.
> 
> AFAICT, the following include files are not used, and could probably be
> binned too:
> config/dbx.h
> config/dbxcoff.h
> config/dbxelf.h
> (+ configi386/gstabs.h Jim found)
> 
> It looks like DBX is the default for:
> i386/cygming configured for 32-bit or lacking PE_SECREL32_RELOC
> i386/darwin.h for 32-bit target
> rx/rx.h when using AS100 syntax
> 
> nathan

Cygwin GCC has been using --with-dwarf2 for sometime now, so it
shouldn't be affected.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 maintainer could comment on the
>>> testcase situation for those targets.
>>
>> Honestly, I'm not sure how ms-bitfields work on non-Windows targets,
> 
> I just noticed that it's handled in generic code in i386.c and the
> affected tests worked on the likes of Linux and Solaris ;-)

gcc/testsuite/gcc.dg/array-quals-1.casm bits probably won't work 
due to object format difference
gcc/testsuite/gcc.dg/lto/20091013-1_1.c I'm not familiar with LTO 
enough to comment on it
gcc/testsuite/gcc.dg/lto/20091013-1_2.c dto.
gcc/testsuite/gcc.dg/pr32370.c  This probably should be safe to 
enable for all.
gcc/testsuite/gcc.dg/pr50251.c  dto.
gcc/testsuite/gcc.dg/tls/thr-cse-1.cI think this should stay as is.
gcc/testsuite/gcc.dg/weak/weak-15.c ELF weak symbols don't really 
work on Windows PE format and are known to be broken
gcc/testsuite/gcc.dg/weak/weak-16.c dto.
gcc/testsuite/gcc.dg/weak/weak-2.c  dto.
gcc/testsuite/gcc.dg/weak/weak-3.c  dto.
gcc/testsuite/gcc.dg/weak/weak-4.c  dto.
gcc/testsuite/gcc.dg/weak/weak-5.c  dto.
libffi/testsuite/libffi.call/cls_longdouble_va.c iirc libffi hasn't been ported 
for 64bit Windows



gcc/testsuite/g++.dg/abi/bitfield3.CShould remain 32bit specific
gcc/testsuite/g++.dg/ext/dllexport3.C   Should be x86_64-*-cygwin too
gcc/testsuite/g++.dg/ext/selectany1.C   dto. 
gcc/testsuite/g++.dg/ext/selectany2.C   dto. 
gcc/testsuite/g++.old-deja/g++.ext/attrib5.CProbably broken due to the 
underscore prefix in asm names for 32bit mingw/cygwin
gcc/testsuite/gcc.dg/dll-3.cShould be x86_64-*-cygwin too
gcc/testsuite/gcc.dg/dll-4.cdto.
gcc/testsuite/gcc.dg/dll-5.cdto.
gcc/testsuite/gcc.dg/dll-8.cdto.
gcc/testsuite/gcc.dg/tree-ssa/loop-1.c  dto.
gcc/testsuite/gcc.target/i386/fastcall-1.c  Keep as is, x86 specific test 
case.

I can't comment on the ARM mingw* port, I have no experience with it.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 confirmed
> that the patched testcases are fine there, two.
> 
> Given that there were no other comments, I've installed the patch.  It
> would still be nice if the Cygwin/MingW maintainer could comment on the
> testcase situation for those targets.
> 
>   Rainer
> 

Honestly, I'm not sure how ms-bitfields work on non-Windows targets,
beyond that, the patch looks like it won't change the tests that run for
mingw/cygwin.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 that Mach-O and [X]COFF support in the simple-object machinery
> is still missing for the early LTO debug feature so I am going to
> break LTOing with DWARF debuginfo on Darwin and Windows (CCing
> maintainers).  Mach-O support has been worked on a bit by Iain
> and myself but the simple-object piece is still missing.
> A workaround is to use stabs on these targets with LTO.
> 
> DWARF part: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01023.html
> simple-object part: 
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01733.html
> 
> both still apply with some fuzz.
> 
> Richard.
> 

AFAIK, LTO doesn't work well on Windows to begin with, if non-LTO modes
are unaffected, I have no issues with this.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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

[JonY]

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 patch
> guidelines.
> 
> Regards,
> 
> Index: libstdc++-v3/config/os/mingw32-w64/os_defines.h
> ===
> --- libstdc++-v3/config/os/mingw32-w64/os_defines.h (revision 247489)
> +++ libstdc++-v3/config/os/mingw32-w64/os_defines.h (working copy)
> @@ -76,6 +76,8 @@
> 
>  #ifdef __x86_64__
>  #define _GLIBCXX_LLP64 1
> +// See libstdc++/69506
> +#define _GLIBCXX_USE_WEAK_REF 0
>  #endif
> 
>  // Enable use of GetModuleHandleEx (requires Windows XP/2003) in
> 

Looks good, go ahead and apply.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 of Wine 64. I had previously submitted
>> these as separate patch sets, but have combined them for simplicity. (Does
>> this make the ChangeLogs too big? Please let me know if you want me to break
>> these back apart.) Below are the included patchsets and a summary of changes
>> since the previous post(s):
> 
> Well, the ChangeLog is acceptable.
> 
> I have comments on how new RTX patterns are generated and checked
> (patches 9/12 and 11/12). Other patches look good to me, so after
> issues with 9/12 and 11/12 are resolved, I think the patch set is
> ready to go.
> 
> After the above issue is addressed, I propose to move forward by
> committing the patchset, and resolve any possible issues later. There
> are just too many code paths in the stack frame construction and
> teardown to notice all possible interactions between new and old code.
> It looks that existing code won't be affected without activating new
> option, so we can be a bit less cautious with the patchset. An
> important part is thus a comprehensive added test suite, which seems
> to pass.
> 
> I also assume that Cygwin and MinGW people agree with the patch and
> the functionality itself.
> 
> Uros.
> 

Cygwin and MinGW does not use SysV/MS transitions directly in their own
code, changes should be OK.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 *p;
-  int fd;
 
   if (__stack_chk_guard != 0)
 return;
@@ -91,7 +90,7 @@
   CryptReleaseContext(hprovider, 0);
 }
 #else
-  fd = open ("/dev/urandom", O_RDONLY);
+  int fd = open ("/dev/urandom", O_RDONLY);
   if (fd != -1)
 {
   ssize_t size = read (fd, &__stack_chk_guard,


Changelog:
2017-04-01  Jonathan Yong  <10wa...@gmail.com>

* ssp.c (__guard_setup): Suppress unused variable warning.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 open shared object file: No such
> file or directory" in all 32-bit tests even after my (fairly crude)
> patch to address that problem.  So as a separate issue, I don't yet have
> a clean patch set to resolve the windows dll search path issue
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867).
> 
> I had to change the test program, as I was dependent upon XSI extensions
> which aren't available on Cygwin, so I'll need to repost that.  Also, I
> had to make one small change in the "aligned SSE MOVs" patch, disabling
> it on SEH targets since gcc/config/i386/winnt.c does not currently
> support the REG_CFA_EXPRESSION note in its unwind emit.  This
> optimization primarily targets 64-bit Wine anyway, where stack
> realignment is now required.
> 
> Daniel
> 

Very nice, thanks for running the tests.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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/msg01153.html
> 
> Best regards,
> 
> Thomas

Looks good to me, thanks.






signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 the right thing to do for the SEH code, go for it.
> 
> jeff
> 
> 

Already applied to trunk, thanks.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 Microsoft Windows can now be configured via
> +--enable-mingw-wildcard or
> --disable-mingw-wildcard
> +to force a specific behavior for GCC itself with regards to supporting or
> +not the wildcard character. Prior versions of GCC would follow the
> 
> Perhaps put "(or not)" in parentheses?
> 
> +configuration of MinGW runtime. This behavior can still be obtained by not
> +using the above options or by using
> +--enable-mingw-wildcard=platform.
> 
> Is this really going to be a question for the Porting Guide, or more
> something you'd put into the release notes (aka changes.html)?  I am
> thinking more the latter.
> 
> This patch is approved for gcc-8/changes.html once GCC 7 has branched
> and gcc-8/changes.html be put in place (though I may be doing that pro-
> actively later today ;-).
> 
> Gerald
> 

It should be part of the release notes since it only affects GCC itself,
not the actual generated output.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 the actual code
> change is committed.
> 

Right, I was waiting for GCC 8 to open.





signature.asc
Description: OpenPGP digital signature

[PATCH] Fix libgfortran build for mingw*

[JonY]

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-win32.h   2017/03/02 11:00:28 245834
+++ trunk/libgcc/config/i386/gthr-win32.h   2017/03/02 11:03:23 245835
@@ -545,6 +545,7 @@
 
 #else /* ! __GTHREAD_HIDE_WIN32API */
 
+#define NOGDI
 #include 
 #include 
 



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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

[JonY]

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 that we're the target frame.  */
   if (ms_exc->ExceptionInformation[1] == (_Unwind_Ptr) this_frame)
 	{
-	  RtlUnwindEx (this_frame, ms_exc->ExceptionInformation[2],
+	  RtlUnwindEx (this_frame, (PVOID) ms_exc->ExceptionInformation[2],
 		   ms_exc, gcc_exc, ms_orig_context,
 		   ms_disp->HistoryTable);
 	  abort ();
@@ -313,7 +313,7 @@
 	  ms_exc->ExceptionInformation[3] = gcc_context.reg[1];
 
 	  /* Begin phase 2.  Perform the unwinding.  */
-	  RtlUnwindEx (this_frame, gcc_context.ra, ms_exc,
+	  RtlUnwindEx (this_frame, (PVOID)gcc_context.ra, ms_exc,
 		   (PVOID)gcc_context.reg[0], ms_orig_context,
 		   ms_disp->HistoryTable);
 	}
@@ -365,7 +365,7 @@
   ms_context.ContextFlags = CONTEXT_ALL;
   RtlCaptureContext (_context);
 
-  RtlUnwindEx ((void *) gcc_exc->private_[1], gcc_exc->private_[2],
+  RtlUnwindEx ((void *) gcc_exc->private_[1], (PVOID)gcc_exc->private_[2],
 	   _exc, gcc_exc, _context, _history);
 
   /* Is RtlUnwindEx declared noreturn?  */


signature.asc
Description: OpenPGP digital signature

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

[JonY]

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.c: new file.
> * config/i386/x-mingw32: Add rule to build driver-mingw32.o.
> * config.host: Link driver-mingw32.o on MinGW host.
> * doc/install.texi: Document new --enable-mingw-wildcard configure
> option.
> 
> Must have forgotten to paste it.

Thanks, I'll stage it locally until stage 1 opens.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 version of the patch,
>> doc/install.texi contains:
>>
>> "Note that this option only affects wildcard expansion for GCC itself. 
>> It does
>> not affect wildcard expansion of executables built by the resulting GCC."
>>
>> If you think a part of that sentence is still confusing please let me
>> know and I'll improve it.
>>
>> Best regards,
>>
>> Thomas
>>
> 
> Yes, that should be good, no more objections.
> 
> 

Before I forget, please also provide a changelog, thanks.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 affects wildcard expansion for GCC itself. 
> It does
> not affect wildcard expansion of executables built by the resulting GCC."
> 
> If you think a part of that sentence is still confusing please let me
> know and I'll improve it.
> 
> Best regards,
> 
> Thomas
> 

Yes, that should be good, no more objections.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 check.
> 
> Of course, ms_abi is gcc's default on Windows so it would be sysv_abi
> functions.  I'm *guessing* that just about everything with Cygwin is
> built for Windows, but it would also make sense if (in some odd case) a
> binary built with sysv_abi is used by something and that library or
> program makes the ABI transition when using said hypothetical library. 
> Even in these cases, I would not anticipate a problem, although any use
> of SEH would inhibit the optimization.  Of course, I haven't *tested*
> this, so I'm only speaking from what I know. :)
> 

Cygwin has internal functions marked ms_abi but none with sysv_abi, so
it will be unaffected by this change. Most 64bit mingw-w64 toolchains
are built with SEH for exception handling though, but since it is
disabled, it shouldn't break anything.

If its not too much to ask, please do a gcc build targeting 32bit/64bit
mingw-w64 and Cygwin, it'll make solid evidence that the changes do not
break the compiler.

Thanks.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 item, I would like to try to get it finished up and
>> tentatively approved as soon as I can.  I have tried to summarize this patch
>> set as clearly and succinctly below as possible.  Thanks!
> 
> You will need a sign-off from cygwin od mingw-w64 maintainer (CC'd).
> While I can review the patch in the sense that it won't break generic
> code, I don't know nothing about mingw-64 to give you any meaningful
> advice.
> 
> Uros.
> 

Hi,

Thanks for the code size reduction patch, I have a few questions:

1. How does code compiled with -moutline-msabi-xlogues interact with
older code compiled without it? Are these only called on ABI transition?

2. Does this mean code compiled with -moutline-msabi-xlogues is not
usable with older GCC? (no a problem, just something to note).

3. Is the old behavior (emit inline code) still default?

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 check.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 was configured. This means if one wants
>>> to build GCC for Windows with a consistent behavior with Wildcard
>>> (enabled or disabled) the mingw runtime must be built as well. This
>>> patch adds an option to GCC configuration to force the behavior with
>>> wildcard when building GCC for Windows host. It does so by setting the
>>> _dowildcard variable in the driver to a given value depending on the
>>> configure option value (yes or no), thus overriding the variable from
>>> mingw runtime.
>>>
>>> Testing: I've successfully done a build of the arm-none-eabi cross GCC
>>> for Windows with Ubuntu system mingw runtime (configured without
>>> wildcard support by default) with the three configure options:
>>>   1) --enable-wildcard: wildcard can be used successfully and nm of
>>> driver-mingw32.o shows that _dowildcard is in .data section
>>>   2) --disable-wildcard: wildcard cannot be used and nm of
>>> driver-mingw32.o shows that _dowildcard is in .bss section
>>>   3) no option: wildcard cannot be used and nm of driver-mingw32.o shows
>>> no _dowildcard defined and all sections are empty
>>>
>>> Is this ok for stage1?
>>>

Looks good, be sure to emphasize this option affects mingw hosted GCC
only, not the compiler output.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 mingw runtime must be built as well. This
> patch adds an option to GCC configuration to force the behavior with
> wildcard when building GCC for Windows host. It does so by setting the
> _dowildcard variable in the driver to a given value depending on the
> configure option value (yes or no), thus overriding the variable from
> mingw runtime.
> 
> Testing: I've successfully done a build of the arm-none-eabi cross GCC
> for Windows with Ubuntu system mingw runtime (configured without
> wildcard support by default) with the three configure options:
>   1) --enable-wildcard: wildcard can be used successfully and nm of
> driver-mingw32.o shows that _dowildcard is in .data section
>   2) --disable-wildcard: wildcard cannot be used and nm of
> driver-mingw32.o shows that _dowildcard is in .bss section
>   3) no option: wildcard cannot be used and nm of driver-mingw32.o shows
> no _dowildcard defined and all sections are empty
> 
> Is this ok for stage1?
> 
> Best regards,
> 
> Thomas

No objections, but documentation should mention that wildcard expansion
is not handled by the CMD shell on Windows, it is up to individual
programs to interpret it.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 -fself-test`
> 
> `/dev/null` is then converted into the Windows null device `nul`
> by the MSYS shell, which is correct. But then the driver adds a
> filename to the name, trying to write the output to `nul.s`.
> `nul` is a reserved filename on Windows. As such it's invalid
> to create this file and the call always fails using CreateFile.
> 
> Checked with x86_64-w64-mingw32 and build gets passed self tests
> but dies at unrelated libstdc++ and libvtv errors.
> 
> Ok for trunk?
> 

Patch is good, go ahead.





signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 easy retrieval?
> 
> Arno
> 

Bottom of the page:
https://patchwork.ozlabs.org/patch/626650/




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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

[JonY]

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 is OK.
> 
> jeff
> 
> 

Modified the patch slightly to include Makefile.tpl.
Tested with Cygwin and cross to mingw-w64.

ChangeLog:
2016-03-26  Corinna Vinschen  <cori...@vinschen.de>

* Makefile.tpl: Add missing OBJCOPY variable.
* Makefile.in: Regenerate.

diff --git a/Makefile.in b/Makefile.in
index 117fbf5..737e602 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -400,6 +400,7 @@ DLLTOOL = @DLLTOOL@
 LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
+OBJCOPY = @OBJCOPY@
 OBJDUMP = @OBJDUMP@
 RANLIB = @RANLIB@
 READELF = @READELF@
diff --git a/Makefile.tpl b/Makefile.tpl
index 94a4f79..597107c 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -403,6 +403,7 @@ DLLTOOL = @DLLTOOL@
 LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
+OBJCOPY = @OBJCOPY@
 OBJDUMP = @OBJDUMP@
 RANLIB = @RANLIB@
 READELF = @READELF@
 Makefile.in  |1 +
 Makefile.tpl |1 +
 2 files changed, 2 insertions(+)




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 is OK.
> 
> jeff
> 
> 


Hi Jeff,

I just realized a similar change is required in Makefile.tpl, how do you
regenerate Makefile.in?




signature.asc
Description: OpenPGP digital signature

[PATCH] Add missing OBJCOPY variable to Makefile.in

[JonY]

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-by: Corinna Vinschen 
---
 Makefile.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile.in b/Makefile.in
index 117fbf5..737e602 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -400,6 +400,7 @@ DLLTOOL = @DLLTOOL@
 LD = @LD@
 LIPO = @LIPO@
 NM = @NM@
+OBJCOPY = @OBJCOPY@
 OBJDUMP = @OBJDUMP@
 RANLIB = @RANLIB@
 READELF = @READELF@
-- 
2.8.3



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 a setup to test cygwin changes, so cannot do it for
> you.
> 

I have already tested it on Cygwin before submitting the test.



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 fixes ada builds for Cygwin.
>>>>
>>>> OK for trunk?
>>>
>>> OK, thanks.
>>>
>>
>> Can someone please commit this? I don't have SVN write access.
>>
>> Thanks.
>>
> 
> Ping?
> 
> 

ping2? Is there a dedicated list for ADA patches?




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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.
>>>
>>> OK for trunk?
>>
>> OK, thanks.
>>
> 
> Can someone please commit this? I don't have SVN write access.
> 
> Thanks.
> 

Ping?




signature.asc
Description: OpenPGP digital signature

Re: Revert gcc r227962

[JonY]

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
>>> other libraries.
>>>
>>> Jeff
>>>
>>
>> I'll need to double check with trunk but gcc-5.3.0 built OK without it.
>> The other alternative is to search /usr/lib before w32api.
>>
>>
> 
> yep it reached stage 3 but failed from another error building target
> libraries (libcilkrts), meaning it was able to find the w32api libraries
> even with this patch reverted.
> 

Has it been reverted? I managed to bootstrap after disabling the failing
libraries.




signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 access.

Thanks.




signature.asc
Description: OpenPGP digital signature

[Patch] Disable text mode translation in ada for Cygwin

[JonY]

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 translation, Cygwin should
follow *Nix behavior. This also fixes build failures on Cywgin.

diff --git a/gcc/ada/sysdep.c b/gcc/ada/sysdep.c
index 465007e..aeaed6d 100644
--- a/gcc/ada/sysdep.c
+++ b/gcc/ada/sysdep.c
@@ -128,15 +128,15 @@ extern struct tm *localtime_r(const time_t *, struct tm 
*);

 #if defined (WINNT) || defined (__CYGWIN__)

+#if defined (__CYGWIN__)
+const char __gnat_text_translation_required = 0;
+void __gnat_set_binary_mode (int handle) {}
+void __gnat_set_text_mode (int handle) {}
+void __gnat_set_mode(int handle, int mode) {}
+#else
 const char __gnat_text_translation_required = 1;

-#ifdef __CYGWIN__
-#define WIN_SETMODE setmode
-#include 
-#else
 #define WIN_SETMODE _setmode
-#endif
-
 void
 __gnat_set_binary_mode (int handle)
 {
@@ -172,6 +172,8 @@ __gnat_set_mode (int handle, int mode)
  }
 }

+#endif __CYGWIN__
+
 #ifdef __CYGWIN__

 char *



signature.asc
Description: OpenPGP digital signature

Re: Revert gcc r227962

[JonY]

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
>>
> 
> I'll need to double check with trunk but gcc-5.3.0 built OK without it.
> The other alternative is to search /usr/lib before w32api.
> 
> 

yep it reached stage 3 but failed from another error building target
libraries (libcilkrts), meaning it was able to find the w32api libraries
even with this patch reverted.




signature.asc
Description: OpenPGP digital signature

Re: Revert gcc r227962

[JonY]

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 alternative is to search /usr/lib before w32api.




signature.asc
Description: OpenPGP digital signature

Re: Revert gcc r227962

[JonY]

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?
>>
>> Kai still needs some time to setup his gcc development environment.
> We'd need to have a better sense of why this is causing problems.  If
> Kai could chime in with a description of the problem it would be helpful.
> 

Normally, /usr/lib is searched BEFORE /usr/lib/w32api. The patch caused
w32api to be searched before /usr/lib.

libuuid.a is known to exist in both directories, with the *nix version
in /usr/lib and the import library for Windows in w32api. The w32api
copy is completely unrelated to the *nix version. This break cygwin apps
that expect to link against *nix libuuid.




signature.asc
Description: OpenPGP digital signature

Revert gcc r227962

[JonY]

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

[JonY]

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 --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
>> @@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see
>>
>>  #undef STARTFILE_SPEC
>>  #define STARTFILE_SPEC "\
>> +  -L%R/usr/lib/w32api \
>>%{!shared: %{!mdll: crt0%O%s \
>>%{pg:gcrt0%O%s}}}\
>>%{shared:crtbeginS.o%s;:crtbegin.o%s} \
>>
>>
> 
> Hello JonY,
> 
> patch is ok with proper ChangeLog.  For sample of format see existing
> ChangeLog files in gcc-subdirectory.
> 
> Thanks,
> Kai
> 

2015-09-16  Jonathan Yong  <10wa...@gmail.com>

* config/i386/cygwin.h (STARTFILE_SPEC): Explicitly search
  sysroot/usr/lib/32api for additional win32 libraries,
  fixes failing Cygwin bootstrapping.

Message OK?



signature.asc
Description: OpenPGP digital signature

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

[JonY]

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 failing Cygwin bootstrapping.

How is that?

>> 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
>> @@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see
>>
>>  #undef STARTFILE_SPEC
>>  #define STARTFILE_SPEC "\
>> +  -L%R/usr/lib/w32api \
>>%{!shared: %{!mdll: crt0%O%s \
>>%{pg:gcrt0%O%s}}}\
>>%{shared:crtbeginS.o%s;:crtbegin.o%s} \
>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature

[PATCH] Fix Cygwin bootstrap failing to find win32 libraries

[JonY]

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
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3.  If not see

 #undef STARTFILE_SPEC
 #define STARTFILE_SPEC "\
+  -L%R/usr/lib/w32api \
   %{!shared: %{!mdll: crt0%O%s \
   %{pg:gcrt0%O%s}}}\
   %{shared:crtbeginS.o%s;:crtbegin.o%s} \




signature.asc
Description: OpenPGP digital signature

Re: Minor Cygwin patches

[JonY]

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  dave.korn.cyg...@googlemail.com

* (gcc/testsuite/gcc.target/i386/pr25993.c): Skip unsupported test.




signature.asc
Description: OpenPGP digital signature

Re: Minor Cygwin patches

[JonY]

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 --large-address-aware, and use
--tsaware for exes
  * (gcc/config/i386/cygwin.h): Add -pthreads, -rdynamic stubs.
  * (gcc/config/i386/cygwin.opt): New file.
 
 Only the link shared libgcc by default part was Dave's; the rest is mine.
 
 

OK

Changelog

2013-03-08  Dave Korn  dave.korn.cyg...@googlemail.com

* (gcc/config/i386/cygwin.h): Link shared libgcc by default.

2013-03-08  Yaakov Selkowitz  yselkow...@users.sourceforge.net

* (gcc/config.gcc): Include Cygwin specific file.
* (gcc/config/i386/cygwin.h): Add --large-address-aware, and use
  --tsaware for exes
* (gcc/config/i386/cygwin.h): Add -pthreads, -rdynamic stubs.
* (gcc/config/i386/cygwin.opt): New file.





signature.asc
Description: OpenPGP digital signature

Re: Minor Cygwin patches

[JonY]

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 some lines about
 cause for those patches.
 

Changelog


2013-03-08  Yaakov Selkowitz yselkow...@users.sourceforge.net

PR 35536
* (libjava/gnu/java/nio/channels/natFileChannelPosix.cc): FIONREAD
returns EINVAL on the errno variable instead of ENOTTY on Cygwin.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35536

--- origsrc/gcc-4.5.1/libjava/gnu/java/nio/channels/natFileChannelPosix.cc  
2007-04-02 20:05:50.0 -0500
+++ src/gcc-4.5.1/libjava/gnu/java/nio/channels/natFileChannelPosix.cc  
2010-10-27 13:39:34.044718100 -0500
@@ -386,7 +386,7 @@ FileChannelImpl::available (void)
 
 #if defined (FIONREAD)
   r = ::ioctl (fd, FIONREAD, num);
-  if (r == -1  errno == ENOTTY)
+  if (r == -1  (errno == ENOTTY || errno == EINVAL))
 {
   // If the ioctl doesn't work, we don't care.
   r = 0;


signature.asc
Description: OpenPGP digital signature

Re: Minor Cygwin patches

[JonY]

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 some lines about
 cause for those patches.
 
 Kai
 

Changelog

2013-03-08  Yaakov Selkowitz yselkow...@users.sourceforge.net

* (gcc/testsuite/gcc.target/i386/pr25993.c): Skip unsupported test.

--- origsrc/gcc-4.5.0/gcc/testsuite/gcc.target/i386/pr25993.c   2008-02-26 
01:38:34.0 +
+++ src/gcc-4.5.0/gcc/testsuite/gcc.target/i386/pr25993.c   2010-04-25 
16:17:21.703125000 +0100
@@ -1,5 +1,5 @@
 /* { dg-do assemble } */
-/* { dg-skip-if  { *-*-darwin* *-*-mingw* } { * } {  } } */
+/* { dg-skip-if  { *-*-darwin* *-*-mingw* *-*-cygwin* } { * } {  } 
} */
 /* { dg-options -std=c99 -x assembler-with-cpp } */
 
 #ifndef __ASSEMBLER__


signature.asc
Description: OpenPGP digital signature

Re: Minor Cygwin patches

[JonY]

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 some lines about
 cause for those patches.
 
 Kai
 

This patch makes gcc accept -pthread and -rdynamic for compatibility
with Linux. Add --large-address-aware, and use --tsaware, only with EXEs.

Changelog

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 --large-address-aware, and use
  --tsaware for exes
* (gcc/config/i386/cygwin.h): Add -pthreads, -rdynamic stubs.
* (gcc/config/i386/cygwin.opt): New file.

Accept -pthread and -rdynamic for compatibility with Linux.
Add --large-address-aware, and use --tsaware, only with EXEs.

--- origsrc/gcc-4.7.2/gcc/config.gcc2012-09-12 04:03:54.0 -0500
+++ src/gcc-4.7.2/gcc/config.gcc2013-03-11 03:41:03.674656700 -0500
@@ -1417,7 +1417,7 @@ i[34567]86-*-cygwin*)
xm_file=i386/xm-cygwin.h
tmake_file=${tmake_file} i386/t-cygming t-slibgcc
target_gtfiles=\$(srcdir)/config/i386/winnt.c
-   extra_options=${extra_options} i386/cygming.opt
+   extra_options=${extra_options} i386/cygming.opt i386/cygwin.opt
extra_objs=winnt.o winnt-stubs.o
c_target_objs=${c_target_objs} msformat-c.o
cxx_target_objs=${cxx_target_objs} winnt-cxx.o msformat-c.o
--- origsrc/gcc-4.7.2/gcc/config/i386/cygwin.h  2012-02-13 15:46:38.0 
-0600
+++ src/gcc-4.7.2/gcc/config/i386/cygwin.h  2013-03-06 00:13:25.986558800 
-0600
@@ -22,7 +22,7 @@ along with GCC; see the file COPYING3.
 #define EXTRA_OS_CPP_BUILTINS()  /* Nothing.  */
 
 #undef CPP_SPEC
-#define CPP_SPEC %(cpp_cpu) %{posix:-D_POSIX_SOURCE} \
+#define CPP_SPEC %(cpp_cpu) %{posix:-D_POSIX_SOURCE} %{pthread: } \
   -D__CYGWIN32__ -D__CYGWIN__ %{!ansi:-Dunix} -D__unix__ -D__unix \
   %{mwin32:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ %{!ansi:-DWINNT}} \
   %{!nostdinc:%{!mno-win32:-idirafter ../include/w32api%s -idirafter 
../../include/w32api%s}}\
@@ -49,11 +49,7 @@ along with GCC; see the file COPYING3.
  %{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
@@ -72,6 +72,7 @@ along with GCC; see the file COPYING3.
 #undef LIB_SPEC
 #define LIB_SPEC \
   %{pg:-lgmon} \
+  %{pthread: } \
   -lcygwin \
   %{mwindows:-lgdi32 -lcomdlg32} \
   -ladvapi32 -lshell32 -luser32 -lkernel32
@@ -115,7 +116,9 @@ along with GCC; see the file COPYING3.
   %{shared: --shared} %{mdll:--dll} \
   %{static:-Bstatic} %{!static:-Bdynamic} \
   %{shared|mdll: --enable-auto-image-base -e __cygwin_dll_entry@12} \
-  --dll-search-prefix=cyg -tsaware
+  --dll-search-prefix=cyg \
+  %{rdynamic: --export-all-symbols} \
+  %{!shared: %{!mdll: --large-address-aware --tsaware}}
 
 /* Binutils does not handle weak symbols from dlls correctly.  For now,
do not use them unnecessarily in gthr-posix.h.  */
--- origsrc/gcc-4.7.2/gcc/config/i386/cygwin.opt1969-12-31 
18:00:00.0 -0600
+++ src/gcc-4.7.2/gcc/config/i386/cygwin.opt2013-03-11 03:36:36.556378400 
-0500
@@ -0,0 +1,27 @@
+; Cygwin-specific options.
+
+; Copyright (C) 2005, 2007, 2009, 2010, 2011 Free Software Foundation, Inc.
+;
+; This file is part of GCC.
+;
+; GCC is free software; you can redistribute it and/or modify it under
+; the terms of the GNU General Public License as published by the Free
+; Software Foundation; either version 3, or (at your option) any later
+; version.
+;
+; GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+; WARRANTY; without even the implied warranty of MERCHANTABILITY or
+; FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+; for more details.
+;
+; You should have received a copy of the GNU General Public License
+; along with GCC; see the file COPYING3.  If not see
+; http://www.gnu.org/licenses/.
+
+pthread
+Driver
+
+rdynamic
+Driver
+
+; Retain blank line above


signature.asc
Description: OpenPGP digital signature