Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
On Sunday 20 November 2022 13:53:48 Pali Rohár wrote:
> Hello! I would like to propose a new parameter for gcc: -mcrtdll= to
> allow specifying against which Windows C Runtime library should be
> binary linked. On Windows there are more crt libraries and currently gcc
> links to libmsvcrt.a which is in most cases symlink to libmsvcrt-os.a
> (but can be changed, e.g. during mingw-w64 building). mingw-w64 project
> already builds import .a library for every crt dll library (from the old
> crtdll.dll up to the new ucrtbase.dll), so it is ready for usage. Simple
> patch for gcc which implements -mcrtdll parameter is below. Note that on
> internet are other very similar patches for -mcrtdll= parameters and
> some are parts of custom mingw32 / mingw-w64 gcc builds. What do you
> think? Could gcc have "official" support for -mcrtdll= parameter?
Hello! I would like to ask gcc people, what do you think about such
proposed -mcrtdll= parameter?
There are lot of unofficial gcc patches which implement this -mcrtdll=
parameter and this parameter is present in more gcc forks.
So it looks like that this parameter is useful for more people.
Here is list of some URLs which I found:
https://sourceforge.net/p/mingw/mailman/message/5692227/
https://sourceforge.net/p/mingw-w64/mailman/message/36030107/
https://github.com/jmeubank/tdm-gcc-src/blob/tdm-patches.public/_PATCHES/mcrtdll.patch
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0006-Windows-New-feature-to-allow-overriding.patch
https://github.com/nak5124/build_env/blob/master/gcc_build/patches/gcc/0020-MinGW-w64-Define-__MSVCRT_VERSION__.patch
But I have not found any discussion about it on gcc mailing list.
>
> --- gcc/config/i386/cygming.opt 2022-02-06 21:00:05.377656896 +0100
> +++ gcc/config/i386/cygming.opt 2022-02-06 21:04:06.690995944 +0100
> @@ -22,6 +22,10 @@ mconsole
> Target RejectNegative
> Create console application.
>
> +mcrtdll=
> +Target RejectNegative Joined
> +Link with specified C RunTime DLL library.
> +
> mdll
> Target RejectNegative
> Generate code for a DLL.
> --- gcc/config/i386/mingw32.h 2022-01-16 17:28:31.157999097 +0100
> +++ gcc/config/i386/mingw32.h 2022-01-16 17:36:03.552856726 +0100
> @@ -95,7 +95,20 @@ along with GCC; see the file COPYING3.
> #undef CPP_SPEC
> #define CPP_SPEC "%{posix:-D_POSIX_SOURCE} %{mthreads:-D_MT} " \
>"%{" SPEC_PTHREAD1 ":-D_REENTRANT} " \
> - "%{" SPEC_PTHREAD2 ": } "
> + "%{" SPEC_PTHREAD2 ": } " \
> + "%{mcrtdll=crtdll*:-U__MSVCRT__ -D__CRTDLL__} " \
> + "%{mcrtdll=msvcrt10*:-D__MSVCRT_VERSION__=0x100} " \
> + "%{mcrtdll=msvcrt20*:-D__MSVCRT_VERSION__=0x200} " \
> + "%{mcrtdll=msvcrt40*:-D__MSVCRT_VERSION__=0x400} " \
> + "%{mcrtdll=msvcrt-os*:-D__MSVCRT_VERSION__=0x700} " \
> + "%{mcrtdll=msvcr70*:-D__MSVCRT_VERSION__=0x700} " \
> + "%{mcrtdll=msvcr71*:-D__MSVCRT_VERSION__=0x701} " \
> + "%{mcrtdll=msvcr80*:-D__MSVCRT_VERSION__=0x800} " \
> + "%{mcrtdll=msvcr90*:-D__MSVCRT_VERSION__=0x900} " \
> + "%{mcrtdll=msvcr100*:-D__MSVCRT_VERSION__=0xA00} " \
> + "%{mcrtdll=msvcr110*:-D__MSVCRT_VERSION__=0xB00} " \
> + "%{mcrtdll=msvcr120*:-D__MSVCRT_VERSION__=0xC00} " \
> + "%{mcrtdll=ucrt*:-D_UCRT} "
>
> /* For Windows applications, include more libraries, but always include
> kernel32. */
> @@ -185,11 +198,16 @@ along with GCC; see the file COPYING3.
> #define REAL_LIBGCC_SPEC \
>"%{mthreads:-lmingwthrd} -lmingw32 \
> " SHARED_LIBGCC_SPEC " \
> - -lmoldname -lmingwex -lmsvcrt -lkernel32"
> + -lmoldname -lmingwex %{!mcrtdll=*:-lmsvcrt} %{mcrtdll=*:-l%*} -lkernel32"
>
> #undef STARTFILE_SPEC
> -#define STARTFILE_SPEC "%{shared|mdll:dllcrt2%O%s} \
> - %{!shared:%{!mdll:crt2%O%s}} %{pg:gcrt2%O%s} \
> +#define STARTFILE_SPEC " \
> + %{shared|mdll:%{mcrtdll=crtdll*:dllcrt1%O%s}} \
> + %{shared|mdll:%{!mcrtdll=crtdll*:dllcrt2%O%s}} \
> + %{!shared:%{!mdll:%{mcrtdll=crtdll*:crt1%O%s}}} \
> + %{!shared:%{!mdll:%{!mcrtdll=crtdll*:crt2%O%s}}} \
> + %{pg:%{mcrtdll=crtdll*:gcrt1%O%s}} \
> + %{pg:%{!mcrtdll=crtdll*:gcrt2%O%s}} \
>crtbegin.o%s \
>%{fvtable-verify=none:%s; \
> fvtable-verify=preinit:vtv_start.o%s; \
>
Re: gcc parameter -mcrtdll= for choosing Windows C RunTime DLL library
在 2022-12-04 20:16, Pali Rohár via Gcc 写道: Hello! I would like to ask gcc people, what do you think about such proposed -mcrtdll= parameter? There are lot of unofficial gcc patches which implement this -mcrtdll= parameter and this parameter is present in more gcc forks. So it looks like that this parameter is useful for more people. I vote +1 for this in GCC 14. GCC 13 (i.e. current master branch) is at stage3 so it's not an option at this moment. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature
gcc-13-20221204 is now available
Snapshot gcc-13-20221204 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20221204/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 24b9337d1f1b5197b6498dceb9074319be003449 You'll find: gcc-13-20221204.tar.xz Complete GCC SHA256=4f919ab2d8503338a3302862a60a3aeb5695be1d24313e6d57253666e3030f6c SHA1=3ef4fafb33b88c5cc5bdeb32861d6829fec8bce1 Diffs from 13-20221127 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: -fprofile-update=atomic vs. 32-bit architectures
On 08/11/2022 11:25, Richard Biener wrote: It would be great to have a code example for the construction of the "if (f()) f();". I think for the function above we need to emit __atomic_fetch_add_8, not the emulated form because we cannot insert the required control flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be lowered after the instrumentation took place. Would it help to change the if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); into unsigned int v = __atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) == 0) v = (unsigned int)(v == 0); __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, __ATOMIC_RELAXED); to get rid of an inserted control flow? On riscv this is optimized to: li a4,1 amoadd.w a5,a4,0(a0) addia5,a5,1 seqza5,a5 addia4,a0,4 amoadd.w zero,a5,0(a4) -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
Re: RFC: Make builtin types only valid for some target features
"Kewen.Lin" writes:
> Hi,
>
> I'm working to find one solution for PR106736, which requires us to
> make some built-in types only valid for some target features, and
> emit error messages for the types when the condition isn't satisfied.
> A straightforward idea is to guard the registry of built-in type under
> the corresponding target feature. But as Peter pointed out in the
> PR, it doesn't work, as these built-in types are used by some built-in
> functions which are required to be initialized always regardless of
> target features, in order to support target pragma/attribute. For
> the validity checking on the built-in functions, it happens during
> expanding the built-in functions calls, since till then we already
> know the exact information on specific target feature.
>
> One idea is to support built-in type checking in a similar way, to
> check if all used type_decl (built-in type) are valid or not somewhere.
> I hacked to simply check currently expanding gimple stmt is gassign
> and further check the types of its operands, it did work but checking
> gassign isn't enough. Maybe I missed something, there seems not an
> efficient way for a full check IMHO.
>
> So I tried another direction, which was inspired by the existing
> attribute altivec, to introduce an artificial type attribute and the
> corresponding macro definition, during attribute handling it can check
> target option node about target feature for validity. The advantage
> is that the checking happens in FE, so it reports error early, and it
> doesn't need a later full checking on types. But with some prototyping
> work, I found one issue that it doesn't support param decl well, since
> the handling on attributes of function decl happens after that on
> attributes of param decl, so we aren't able to get exact target feature
> information when handling the attributes on param decl. It requires
> front-end needs to change the parsing order, I guess it's not acceptable?
> So I planed to give up and return to the previous direction.
>
> Does the former idea sound good? Any comments/suggestions, and other
> ideas?
>
> Thanks a lot in advance!
FWIW, the aarch64 fp move patterns emit the error directly. They then
expand an integer-mode move, to provide some error recovery. (The
alternative would be to make the error fatal.)
(define_expand "mov"
[(set (match_operand:GPF_TF_F16_MOV 0 "nonimmediate_operand")
(match_operand:GPF_TF_F16_MOV 1 "general_operand"))]
""
{
if (!TARGET_FLOAT)
{
aarch64_err_no_fpadvsimd (mode);
machine_mode intmode
= int_mode_for_size (GET_MODE_BITSIZE (mode), 0).require ();
emit_move_insn (gen_lowpart (intmode, operands[0]),
gen_lowpart (intmode, operands[1]));
DONE;
}
This isn't as user-friendly as catching the error directly in the FE,
but I think in practice it's going to be very hard to trap all invalid
uses of a type there. Also, the user error in these situations is likely
to be forgetting to enable the right architecture feature, rather than
accidentally using the wrong type. So an error about missing architecture
features is probably good enough in most cases.
Thanks,
Richard
Re: -fprofile-update=atomic vs. 32-bit architectures
On Mon, Dec 5, 2022 at 8:26 AM Sebastian Huber wrote: > > On 08/11/2022 11:25, Richard Biener wrote: > >> It would be great to have a code example for the construction of the "if > >> (f()) f();". > > I think for the function above we need to emit __atomic_fetch_add_8, > > not the emulated form because we cannot insert the required control > > flow (if (f()) f()) on an edge. The __atomic_fetch_add_8 should then be > > lowered after the instrumentation took place. > > Would it help to change the > > if (__atomic_add_fetch_4 ((unsigned int *) &val, 1, __ATOMIC_RELAXED) > == 0) >__atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, > __ATOMIC_RELAXED); > > into > > unsigned int v = __atomic_add_fetch_4 ((unsigned int *) &val, 1, > __ATOMIC_RELAXED) > == 0) > v = (unsigned int)(v == 0); > __atomic_fetch_add_4 (((unsigned int *) &val) + 1, 1, > __ATOMIC_RELAXED); that's supposed to add 'v' instead of 1? Possibly use uint32_t here (aka uint32_type_node). > > to get rid of an inserted control flow? That for sure wouldn't require any changes to how the profile instrumentation works, so yes it would be simpler. Richard. > On riscv this is optimized to: > > li a4,1 > amoadd.w a5,a4,0(a0) > addia5,a5,1 > seqza5,a5 > addia4,a0,4 > amoadd.w zero,a5,0(a4) > > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/
