Re:Re: [PATCH] libstdc++-v3: Check for TLS support on mingw

[lhmouse via Gcc-patches]

在 2021-08-31 17:02, Jonathan Wakely 写道:
> It looks like my questions about this patch never got an answer, and
> it never got applied.
> 
> Could somebody say whether TLS is enabled for native *-*-mingw*
> builds? If it is, then we definitely need to add GCC_CHECK_TLS to the
> cross-compiler config too.
> 
> For a linux-hosted x86_64-w64-mingw32 cross compiler I see TLS is not enabled:
> 
> /* Define to 1 if the target supports thread-local storage. */
> /* #undef _GLIBCXX_HAVE_TLS */
> 

I have been disabling it with `--disable-tls` for years, but... I couldn't 
remember why. Thread-local storage is implemented with emutls, no matter with 
or without this option.

Does 'thread-local storage' mean to access thread-local objects via the FS or 
GS register on x86? If so, then it is definitely not supported yet.


-- 
Best regards,
LIU Hao

Where can I get copyright assignment/disclaimer forms for contribution to gcc ?

[lhmouse]

Dear GCC developers,

I have created a patch for enabling diagnostic colors on Windows. In order to 
allow the patch to be integrate with GCC, I need the copyright 
assignment/disclaimer forms, according to 
. Our MinGW target maintainer, jon_y, is 
also interested in the patch. While we have no idea about the process about 
submitting patches, we need some guidance about:

1. where I get the copyright assignment or disclaimer forms, and
2. what I do with that form (from 
 I learned that 
I print it, sign it, then send back a scanned copy of it, is that enough?), and
3. which format I use for the patch (it was generated using Git rather than 
SVN), the changelog, etc.

Thanks in advance.

-- 
Best regards,
LH_Mouse

Re: use of exceptions in GCC

[lhmouse]

> GCC is built with -fno-exceptions.  I assume that's mainly to avoid
> having to catch and handle exceptions in what was originally C code.
> I also assume that also means that there's a policy or convention in
> place against throwing exceptions in GCC or making use of constructs
> that might throw (such as the non-placement new expressions).
It also drops the need of _runtime type info_ (a.k.a. RTTI) and stack unwind
table, reducing the size of binary files.

> 
> By coincidence, bootstrapping my patch for bugs 77531 and 78284
> exposed a few uses of the non-placement array new expression in
> dominance.c (in dom_info::dom_init) that may throw an exception(*).
> 
> I'm wondering if those calls should be changed to avoid exceptions.
If a program is compiled with `-fno-exceptions` and an exception
will have been thrown otherwise, `std::abort()` (or an equivalent such as
`__builtin_trap()`) is called. This preserves the semantical correctness
of not checking the value of a throwing new expression,
since it can't return a null pointer.

> 
> I'm also curious if there really is a policy/convention for dealing
> with exceptions in GCC, what it actually is/says.
Compilers aren't envisioned to be long-running programs, so aborting
on unexpected conditions is reasonable. This isn't only the case for GCC,
but also LLVM.

> 
> Thanks
> Martin
> 
> [*] My patch exposed these because when -fno-exceptions is used
> (and coincidentally also in C++ 98 mode) GCC emits conditional calls
> to operator new[](SIZE_MAX) when the size computation that multiplies
> the number of elements by the element size exceeds SIZE_MAX.  The
> -Walloc-size-larger-than warning flags for attempting to allocate
> more storage than the size of the biggest object, or SIZE_MAX / 2.



--   
Best regards,
lh_mouse
2016-11-17

Re: Re: Make GCC emit ASM instructions in 'gcc/except.c' for i686 MinGW targets ?

[lhmouse]

> I'd probably create a new exception handling model and conditionalize 
> whatever code you need based on that. 

That would require copy-n-paste of tons of code...
All this remains contingent on Microsoft's generosity because
they don't provide APIs for SEH on x86, unlike on x64.
So I have to reuse stack unwinding code from SJLJ at the moment.

> Emission of code for that new 
> exception model would likely require some amount of target specific code 
> called via target hooks.

Hooks... Er, are you talking about those global pointer-to-functions?
There are a lot, indeed.

--   
Best regards,
lh_mouse
2016-10-17

Make GCC emit ASM instructions in 'gcc/except.c' for i686 MinGW targets ?

[lhmouse]

Hi there,

I come up with an idea about implementing stack unwinding for
the i686-w64-mingw32 target using native Windows Structured
Exception Handling (a.k.a SEH) for efficiency reasons.

Unlike DWARF and SEH for x64, SEH for x86 is stack-based
and works like the SJLJ exception model: The operating system
keeps a thread specific pointer to an SEH node on the stack
that must be installed/uninstalled during run time.

The SEH-head pointer is stored in `fs:[0]`.
Typecially, an SEH handler is installed like this, in Intel syntax:

# typedef EXCEPTION_DISPOSITION
#   filter_function(
# EXCEPTION_RECORD *record, void *establisher_frame,
# CONTEXT *machine_context, void *dispatcher_context)
#   __attribute__((__cdecl__));
# struct x86_seh_node_header {
#   struct x86_seh_node_header *next;
#   filter_function *filter;
#   char extra_data[];
# };

sub esp, 8  # struct x86_seh_node_header this_node;
mov ecx, dword ptr fs:[0]   # 
mov dword ptr[esp], ecx # this_node.next = get_thread_seh_head();
mov dword ptr[esp + 4], offset my_seh_filter
# this_node.filter = _seh_filter
mov dword ptr fs:[0], esp   # set_thread_seh_head(_node);

Before the function exits and its frame is destroyed, the node
must be uninstalled like this:

mov ecx, dword ptr fs:[0]   #
mov dword ptr fs:[0], ecx   # set_thread_seh_head(this_node.next);

Since I am looking at the SJLJ exception model and it seems using
a slim, inlined version of `setjmp()` with `__builtin_longjmp()`
that only stores 3 or 4 pointers, extending that structure should be
a simple matter. The problem is that, installation and uninstallation
of SEH nodes require target-specific ASM code generation.

Is it possible to do in 'gcc/except.c' ?


--
Best regards,
lh_mouse
2016-10-17

Re: Re: [PATCH] Fixed up missing semicolons.

[lhmouse]

In case my previous mail is swallowed by mailman:

I am not familiar with your convention. Elsewhere, I usually
don't use my full name. If people suggest I use a full name
when submitting patches, I am glad to go with that.

My name is Liu Hao (LH for short). The word 'Mouse' is
a homophony joke in Chinese and does not mean anything
significant.

--   
Best regards,
lh_mouse
2016-09-27

[PATCH] Fixed up missing semicolons.

[lhmouse]

Hi GCC developers,
Today I was trying bootstrapping GCC 7.0.0 and stage 1 compilation
failed because of two missing semicolons. After this patch was applied,
xgcc could be built successfully, although it still failed the self-test.

--
Best regards,
lh_mouse
2016-09-23



From 1133ae49102751b24cfd0368986a63f482afe8d0 Mon Sep 17 00:00:00 2001
From: lhmouse <lh_mo...@126.com>
Date: Fri, 23 Sep 2016 19:11:03 +0800
Subject: [PATCH] Fixed up missing semicolons.

Signed-off-by: lhmouse <lh_mo...@126.com>
---
 gcc/config/i386/cygming.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index 60e11b4..1d9675e 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -111,7 +111,7 @@ along with GCC; see the file COPYING3.  If not see
assemble_name (FILE, LABEL);\
if ((OFFSET) != 0)  \
  fprintf (FILE, "+" HOST_WIDE_INT_PRINT_DEC,   \
-  (HOST_WIDE_INT) (OFFSET))\
+  (HOST_WIDE_INT) (OFFSET));   \
break;  \
   case 8:  \
/* This is a hack.  There is no 64-bit section relative \
@@ -123,7 +123,7 @@ along with GCC; see the file COPYING3.  If not see
assemble_name (FILE, LABEL);\
if ((OFFSET) != 0)  \
  fprintf (FILE, "+" HOST_WIDE_INT_PRINT_DEC,   \
-  (HOST_WIDE_INT) (OFFSET))\
+  (HOST_WIDE_INT) (OFFSET));   \
fputs ("\n\t.long\t0", FILE);   \
break;  \
   default: \
-- 
2.9.1


0016-master-Fixed-up-missing-semicolons.patch
Description: Binary data

Re: fxsrintrin.h

[lhmouse]

Given the `_fxsave()` function returning `void`, it is invalid C but valid C++:

# WG14 N1256 (C99) / N1570 (C11)
6.8.6.4 The return statement
Constraints
1 A return statement with an expression shall not appear in a function
whose return type is void. ...

# WG21 N1804 (C++03)
6.6.3 The return statement [stmt.return]
3 A return statement with an expression of type “cv void” can be used
only in functions with a return type of cv void; the expression
is evaluated just before the function returns to its caller.

# WG21 N4582 (C++1z)
6.6.3 The return statement [stmt.return]
2 ... A return statement with an operand of type void shall be used
only in a function whose return type is cv void. ...


--   
Best regards,
lh_mouse
2016-08-19

-
发件人：David Wohlferd 
发送日期：2016-08-19 11:51
收件人：gcc@gcc.gnu.org
抄送：
主题：fxsrintrin.h

According to the docs 
(https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html), 
__builtin_ia32_fxsave() has return type 'void.'  Given that, does this 
code (from gcc/config/i386/fxsrintrin.h) make sense?

 _fxsave (void *__P)
 {
   return __builtin_ia32_fxsave (__P);
 }

Returning a void?  Is that a thing?  Similar question for _fxrstor, 
_fxsave64, and _fxrstor64.

And again in xsaveintrin.h for _xsave, _xrstor, _xsave64 and _xrstor64?

dw

Re: Possible missed optimization opportunity with const?

[lhmouse]

In your example the compiler is not given the guarantee that
the object 'foo' in question can only be modified through the pointer.

We can make such guarantee by adding the `restrict` qualifier
to the pointer, like this:

const int *restrict pfoo = 

With -O3 on GCC 6.1 the modified code produces:

a: 1, b: 1

However as long as there is a restrict pointer pointing to an object,
modifying it _not_ through that pointer results in undefined behavior.

--   
Best regards,
lh_mouse
2016-08-17

-
发件人：Toshi Morita 
发送日期：2016-08-17 08:21
收件人：gcc@gcc.gnu.org
抄送：
主题：Possible missed optimization opportunity with const?

I was involved in a discussion over the semantics of "const" in C, and the 
following code was posted: 

#include 
int foo = 0;
const int *pfoo = 
void bar (void)
{
foo +=3D;
}
int main(void)
{
   int a, b;
   a = *pfoo;
 bar();
 b = *pfoo;
   printf("a: %d, b: %d\n", a, b);
}
 

This code when compiled with gcc 4.8.2 using the optimization option -O3 
produces: 

a: 0, b: 1 


So it appears even though pfoo is a const int *, the value *pfoo is read twice. 

Would it be valid for the code to print a:0, b: 0?
If so, is this a missed optimization opportunity?

Toshi