Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
We use neither --with-sysroot nor --with-build-sysroot.
The reason is that, the hard-coded path in GCC repository - that is, the
/mingw/ one - does not actually exist.
In order to build GCC for mingw targets, we take either solution:
0) Make a symlink (or rather, a copy, since Windows does not support symlinks)
as /mingw/, as mentioned in
https://sourceforge.net/p/mingw-w64/wiki2/Native%20Win64%20compiler/
1) Replace the non-existent path with an existent one, as done in
https://github.com/lhmouse/MINGW-packages/blob/master/mingw-w64-gcc-git/PKGBUILD#L112
--
Best regards,
lh_mouse
2016-05-10
-
发件人：Andrew Pinski
发送日期：2016-05-10 05:10
收件人：Brett Neumeier
抄送：lh_mouse,Jonathan Wakely,gcc
主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
On Mon, May 9, 2016 at 1:31 PM, Brett Neumeier wrote:
> On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote:
>> Should I file a bug report then?
>> We need some Linux testers, though not many people on Linux relocate
>> compilers.
>
> For what it's worth -- I encountered the same problem on a GNU/Linux
> system. In my specific situation, I'm cross-compiling GCC using an
> AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in
> a sysroot directory. When I try to use that GCC on a target device
> where (of course) the sysroot directory becomes "/", the hard-coded
> "/path/to/sysroot" from the host system is still used to find the C++
> headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25:
> fatal error: stdlib.h: No such file or directory" error message you
> got.
>
> Changing #include_next to #include in cstdlib and cmath fixed my
> problem -- so, thank you very much for this discussion! It helped at
> least one other person.
>
> Please let me know if there's any other testing I can do to help.
This sounds like a good use of --with-build-sysroot instead of just
--with-sysroot.
I use the following for the candian cross:
--with-sysroot=/ --with-build-sysroot=${SYSROOT}
Thanks,
Andrew
>
> Cheers,
>
> Brett
Re: Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows
I have a vision. It is gcc/gcc/incpath.c that the problem is in. I had been looking through that file for a few days but eventually gave up. It is worth mentioning that adding an '-iprefix /this/need/not/exist' vanishes the problem. This might have something to do with the following line in incpath.c (it should be line #132 on gcc-6-branch at the moment): ``` if (iprefix && (len = cpp_GCC_INCLUDE_DIR_len) != 0) ``` Still I have no idea about how relocated paths are pulled in. I am looking forward to a patch for the relocation problem. -- Best regards, lh_mouse 2016-05-10 - 发件人：Brett Neumeier 发送日期：2016-05-10 04:31 收件人：lh_mouse 抄送：Jonathan Wakely,gcc 主题：Re: Re: GCC 6.1 Hard-coded C++ header paths and relocation problem on Windows On Tue, May 3, 2016 at 10:01 AM, lh_mouse wrote: > Should I file a bug report then? > We need some Linux testers, though not many people on Linux relocate > compilers. For what it's worth -- I encountered the same problem on a GNU/Linux system. In my specific situation, I'm cross-compiling GCC using an AMD64-to-mips64el cross-toolchain, and installing the resulting GCC in a sysroot directory. When I try to use that GCC on a target device where (of course) the sysroot directory becomes "/", the hard-coded "/path/to/sysroot" from the host system is still used to find the C++ headers, resulting in the same ".../include/c++/6.1.1/cstdlib:75:25: fatal error: stdlib.h: No such file or directory" error message you got. Changing #include_next to #include in cstdlib and cmath fixed my problem -- so, thank you very much for this discussion! It helped at least one other person. Please let me know if there's any other testing I can do to help. Cheers, Brett
Re: GNU C: Implicit int and implicit function definitions
Implicit function declarations result in warnings since C99 or GNU99 and '-pedantic-errors' turns them into errors. The same goes for implicit return types. -- Best regards, lh_mouse 2016-05-20 - 发件人：Florian Weimer 发送日期：2016-05-20 16:17 收件人：GCC 抄送： 主题：GNU C: Implicit int and implicit function definitions I just spend an hour hunting down someone else's GCC code generation bug, when it turned out it was caused by an implicit function definition, where the real return type was incompatible with int. C99 got rid of implicit function definitions and implicit ints. Would it be possible to remove them retroactively from the -std=gnu99 and -std=gnu11 language variants (as well as -std=c99 and -std=c11), so that they are rejected by default? Thanks, Florian
Contribute to GCC - the MCF thread model for MinGW targets
Hello GCC developers, I have implemented a gthread library for both the i686 and x86_64 MinGW targets, which supports all c++0x thread features required by . This library is experimental and stil lrequires testing. However Kai suggested I donate it to the FSF so it could be merged into the GCC upstream. I am looking at this https://gcc.gnu.org/contribute.html , but here I have a few questions: 0) Legal Prerequisites In order to add a new thread model, a new library has to be introduced since on Windows TLS destructors can't be implemented without either hacking the CRT or using a shared library. The source code of the mcfgthread library can be found here: https://github.com/lhmouse/mcfgthread . It is essential to link against this library dynamically. All headers of this library are put into the public domain and the rest are licensed under the GNU LGPL. See MCFLicense.txt for details. Adding a new thread model requires modifying GCC source. The patch can be found here: https://github.com/lhmouse/MINGW-packages/blob/mcfgthread/mingw-w64-gcc-git/9000-gcc-6-branch-Added-mcf-thread-model-support-from-mcfgthread.patch Because it applies to GCC source, I would grant you GCC developers the right to do whatever you want with this patch, including re-licensing. Is this sufficient? 1) About 'Coding Standards': Most code is done in the mcfgthread library and I try to keep modification of GCC source as little as possible. Thus, do I still have to have regard for the GNU coding standard in the standalone library? I have my own coding style indeed. I will accept any of your suggestions for the patch to the GCC source, of course. 2) About 'Testing Patches': mcfgthread fails the following test: gcc/libstdc++-v3/testsuite/30_threads/recursive_mutex/unlock/1.cc This test tries to unlock an unlocked recursive_mutex. According to ISO C++ this is undefined behavior and it causes an assertion failure (thus abnormal termination) in mcfgthread. The source code of __gthread_recursive_mutex_unlock() function can be found here: https://github.com/lhmouse/mcfgthread/blob/master/src/env/gthread.h#L171 I suggest we drop this test. Any further discussion is welcome. -- Best regards, lh_mouse 2016-06-12
Re: RE: [Mingw-w64-public] Contribute to GCC - the MCF thread model for MinGWtargets
mcfgthread isn't a pthread implementation. Roughly, gthread is a subset of
pthread.
The gthread interfaces are defined in , which should be part of
libstdc++ headers installed.
The history of mcfgthread is a long story... Well, please bear with me.
Once upon a time I was compiling libcxx with libwinpthread... well it failed
because ISO C++ requires the default constructor of `std::mutex` to be
`constexpr`.
libwinpthread, however, defines `pthread_mutex_t` as `void *` and
`PTHREAD_MUTEX_INITIALIZER` as `(void *)-1`, which violates the standard
because it would need to involve a `reinterpret_cast` to work (note that `(void
*)-1` is equivalent to `reinterpret_cast(static_cast(-1))` ).
clang++ is correct to reject the code.
For whatever reason, GCC accepted the code. Then I asked in #mingw-w64 on OFTC
why didn't its author (probably Kai, I am not sure) define
`PTHREAD_MUTEX_INITIALIZER` as a plain `0`.
Kai answered, the magical value `(void *)-1` existed to mark a mutex as 'to be
initialized on first use'. So did `(void *)-3` to mark it as 'to be initialized
as a recursive mutex on first use' etc.
Then I started to look into its source code and found the implementation of
winpthread very very problematic.
The issues of winpthreads are:
0) It is very inefficient, probably due to Windows XP compatibility.
1) Its initializers violate the C++ standard, despite GCC's acceptance.
2) Its mutex and condition variable can't be trivially destructed unlike those
on Linux.
And a few more...
Then I thought it was time to write a new thread library.
But I didn't want to reinvent winpthread because it would be an overkill. Then
the `win32` thread model of GCC came into my sight.
> 'It is working despite lack of std::thread support, isn't it?'
Then I forked MCFCRT for a clean room design of a thread library that would
meet the minimum requirements of GCC with c++0x thread, more than the win32
thread model of course.
It didn't take me long to discover . Then I sent this mail to the GCC
mailing list: https://gcc.gnu.org/ml/gcc/2016-04/msg00080.html (I appreciate
Jonathan Wakely's kindly support.)
The result was mcfgthread.
0) Its mutex is 10x times faster than the one in .
1) Its mutex, condition variable and once-initialization flag can be
zero-initialized with `{ 0 }` in C and C++98, and just `{ }` since C++0x,
conforming to the standard.
2) A mutex, condition variable or once-initialization flag has the same size of
a pointer and allocates no kernel object or extra memory. They can be trivially
destructed without resource leaks.
3) It enables GCC libraries to be built with full C++0x thread support.
The drawbacks of mcfgthread:
0) It can't be linked statically without hacking the CRT.
1) It is not claimed to support Windows NT 5.x or below. That is, Windows XP
and Windows Server 2003.
Well... if we bear with it, we have at least an efficient and c++0x conforming
thread implementation for GCC on MinGW targets.
--
Best regards,
lh_mouse
2016-06-12
---------
发件人：Ruben Van Boxem
发送日期：2016-06-12 15:48
收件人：lh mouse,gcc,mingw-w64-public
抄送：
主题：RE: [Mingw-w64-public] Contribute to GCC - the MCF thread model
for MinGWtargets
Hi!
I do wonder how this compares with e.g. the MinGW-stdthread header only
implementaion on github. As far as I remember, the author explicitly relicensed
his code so it could be used for the same purpose. How dies it compare to your
implementation?
Since the ABI of the toolchain will be different when built against your
intermediate library, what is the advantage over say, winpthreads or just
providing a direct win32 implementation of gthreads in libgcc proper? It seems
to me that instead of linking to mcfthreads, the right way forward would be to
integrate this code into libgcc directly, no?
Just me 2 cents in this…
Ruben
Van: lh mouse
Verzonden: zondag 12 juni 2016 8:51
Aan: gcc; mingw-w64-public
Onderwerp: [Mingw-w64-public] Contribute to GCC - the MCF thread model for
MinGWtargets
Hello GCC developers,
I have implemented a gthread library for both the i686 and x86_64 MinGW
targets, which supports all c++0x thread features required by .
This library is experimental and stil lrequires testing. However Kai suggested
I donate it to the FSF so it could be merged into the GCC upstream.
I am looking at this https://gcc.gnu.org/contribute.html , but here I have a
few questions:
0) Legal Prerequisites
In order to add a new thread model, a new library has to be introduced since on
Windows TLS destructors can't be implemented without either hacking the CRT or
using a shared library.
The source code of the mcfgthread library can be found here:
https://github.com/lhmouse/mcfgthread .
It is essential to link against this library dynamically. All headers of this
librar
Potential bug about the order of destructors of static objects and atexit() callbacks in C++?
Hello GCC developers,
Reading the ISO C++ standard,
> 3.6.4 Termination [basic.start.term]
> 3 If the completion of the initialization of an object with
> static storage duration is sequenced before a call to std::atexit
> (see , 18.5), the call to the function passed to std::atexit
> is sequenced before the call to the destructor for the object. ...
Notwithstanding the vagueness of 'the completion of the initialization of an
object',
the following program:
#include
#include
enum class state {
null,
initialized,
destroyed,
};
extern void broken_atexit();
struct global_data {
state s;
global_data()
: s(state::null)
{
std::puts("delegated constructor");
}
global_data(int)
: global_data()
{
s = state::initialized;
std::atexit(&broken_atexit);
std::puts("delegating constructor");
}
~global_data(){
s = state::destroyed;
}
} data(1);
void broken_atexit(){
if(data.s == state::destroyed){
std::puts("attempt to use a destroyed object?");
std::abort();
}
std::puts("okay");
}
int main(){
}
, when compiled with GCC, results in use of a destroyed object:
lh_mouse@lhmouse-dev:~$ g++ test.cc -std=c++11
lh_mouse@lhmouse-dev:~$ ./a.out
delegated constructor
delegating constructor
attempt to use a destroyed object?
Aborted
lh_mouse@lhmouse-dev:~$
The reason of this problem is that GCC front-end registers the dtor after
the delegating constructor returns, which is invoked before the other
callback registered inside the delegating constructor body.
The problem would be gone only if the GCC front-end registers the dtor after
the delegated constructor returns.
Is this a GCC bug?
--
Best regards,
lh_mouse
2016-08-01
