Re: Inconsistent segmentation fault in GCC
On Thu, 23 Dec 2021, 06:07 Alessandro Baretta via Gcc, wrote: > > How I might help diagnose and fix this bug? For instance, how does one > run gcc from inside gdb? I know that gcc is just the driver and > cc1plus is the actual compiler, so I presume I'd have to run cc1plus > inside gdb, but as far as I know cc1plus cannot be called directly. > That's not true, it can be run directly. The full cc1plus command is shown if you add -v to your GCC command. https://gcc.gnu.org/wiki/DebuggingGCC has some more tips.
Re: New ThreadSanitizer runtime (v3)
On 11/30/21 05:17, Dmitry Vyukov wrote: On Mon, 29 Nov 2021 at 19:16, Martin Liška wrote: On 11/22/21 20:01, Dmitry Vyukov wrote: I've already reverted the change. So I will include a fix into the next version. Thanks for notifying. Hello. Am I correct that the patch set is installed again? Any near future plans for another revert of the patch? Do you think it's the right time to merge it to GCC? It has been re-landed at least twice since then :) Well, I can't promise that it won't be reverted again. I obviously do not want that. Hard to say. I need to send some follow up clean up patches and I plan to wait till the end of the week (to avoid messy multi commit reverts). So if there are no deadlines to miss, I would suggest waiting until the beginning of the next week. Hello. May I please ask about the status of TSANv3? Note we'll flip to stage4 stage in about 3 weeks and so I'm curious if we want to do one more merge from upstream? @Jakub: What do you think about it? Cheers, Martin
Re: New ThreadSanitizer runtime (v3)
On Thu, 23 Dec 2021 at 13:10, Martin Liška wrote: > >> On 11/22/21 20:01, Dmitry Vyukov wrote: > >>> I've already reverted the change. So I will include a fix into the next > >>> version. > >>> Thanks for notifying. > >> > >> Hello. > >> > >> Am I correct that the patch set is installed again? Any near future plans > >> for another > >> revert of the patch? Do you think it's the right time to merge it to GCC? > > > > It has been re-landed at least twice since then :) > > Well, I can't promise that it won't be reverted again. I obviously do > > not want that. Hard to say. I need to send some follow up clean up > > patches and I plan to wait till the end of the week (to avoid messy > > multi commit reverts). > > So if there are no deadlines to miss, I would suggest waiting until > > the beginning of the next week. > > Hello. > > May I please ask about the status of TSANv3? Note we'll flip to stage4 stage > in about > 3 weeks and so I'm curious if we want to do one more merge from upstream? > > @Jakub: What do you think about it? Hi Martin, I re-laned it last time 10 days ago: b332134921b4 Mon, 13 Dec 2021 12:48:34 +0100 tsan: new runtime (v3) at this point it wasn't yet reverted... Few more issues were fixed and it now survived testing in Chromium. I hope it won't be reverted anymore... but can't promise (it's not me who revert it :)) I would say if we wait a few more days maybe, it's reasonably safe to assume it sticks.
Many analyzer failures on non-Linux system (x86_64-apple-darwin)
Hi David, hi everone, I’m trying to understand how best to fix or silence the several failures in gcc.dg/analyzer that occur on x86_64-apple-darwin. Some of them, according to gcc-testresults, also occur on other non-Linux targets. See for example, the test results at https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html ## gcc.dg/analyzer/torture/asm-x86-linux-*.c Are these supposed to be run only on Linux (as the name implies)? Four of them fail on x86_64-apple-darwin, because they use assembly that is not supported: FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c FAIL: gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c Should they be restricted to Linux targets? There is another one that has the same error, as well, although it doesn’t have linux in the name: FAIL: gcc.dg/analyzer/asm-x86-lp64-1.c ## Builtin-related failures Those four cases fail: gcc.dg/analyzer/data-model-1.c gcc.dg/analyzer/pr103526.c gcc.dg/analyzer/taint-size-1.c gcc.dg/analyzer/write-to-string-literal-1.c but pass if the function calls (memset and memcpy) are replaced by the built-in variant (__builtin_memset and __builtin_memcpy). The reason for that is the darwin headers, in (included from ) does this: #if __has_builtin(__builtin___memcpy_chk) || defined(__GNUC__) #undef memcpy /* void *memcpy(void *dst, const void *src, size_t n) */ #define memcpy(dest, ...) \ __builtin___memcpy_chk (dest, __VA_ARGS__, __darwin_obsz0 (dest)) #endif where __darwin_obsz0 is defined thusly: #define __darwin_obsz0(object) __builtin_object_size (object, 0) Does the analyzer not handle the _chk builtin variants? Should it? I’m happy to investigate more, but I’m not sure what to do. Best, FX
_Float16-related failures on x86_64-apple-darwin
Hi, Some recently introduced tests have been failing for several weeks on x86_64-apple-darwin. FAIL: gcc.target/i386/cond_op_maxmin__Float16-1.c FAIL: gcc.target/i386/pr102464-copysign-1.c FAIL: gcc.target/i386/pr102464-fma.c FAIL: gcc.target/i386/pr102464-maxmin.c FAIL: gcc.target/i386/pr102464-sqrtph.c FAIL: gcc.target/i386/pr102464-sqrtsh.c FAIL: gcc.target/i386/pr102464-vrndscaleph.c In all cases the symptom is the same: the include of errors out with “Unsupported value of __FLT_EVAL_METHOD__”. It appears that the compile option -mavx512fp16 defines __FLT_EVAL_METHOD__ to have value 16, which is not understood by darwin: > /* Define float_t and double_t per C standard, ISO/IEC 9899:2011 7.12 2, > taking advantage of GCC's __FLT_EVAL_METHOD__ (which a compiler may > define anytime and GCC does) that shadows FLT_EVAL_METHOD (which a > compiler must define only in float.h). > */ > #if __FLT_EVAL_METHOD__ == 0 > typedef float float_t; > typedef double double_t; > #elif __FLT_EVAL_METHOD__ == 1 > typedef double float_t; > typedef double double_t; > #elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1 > typedef long double float_t; > typedef long double double_t; > #else /* __FLT_EVAL_METHOD__ */ > # error "Unsupported value of __FLT_EVAL_METHOD__." > #endif /* __FLT_EVAL_METHOD__ */ Is the use of __FLT_EVAL_METHOD__ set to 16 supposed to be portable across all targets? Or is it linux-only, and should marked as such? Thanks for any help you can give. FX
Re: _Float16-related failures on x86_64-apple-darwin
On Thu, Dec 23, 2021, 14:24 FX via Gcc wrote: > Hi, > > Some recently introduced tests have been failing for several weeks on > x86_64-apple-darwin. > > FAIL: gcc.target/i386/cond_op_maxmin__Float16-1.c > FAIL: gcc.target/i386/pr102464-copysign-1.c > FAIL: gcc.target/i386/pr102464-fma.c > FAIL: gcc.target/i386/pr102464-maxmin.c > FAIL: gcc.target/i386/pr102464-sqrtph.c > FAIL: gcc.target/i386/pr102464-sqrtsh.c > FAIL: gcc.target/i386/pr102464-vrndscaleph.c > > In all cases the symptom is the same: the include of errors out > with “Unsupported value of __FLT_EVAL_METHOD__”. It appears that the > compile option -mavx512fp16 defines __FLT_EVAL_METHOD__ to have value 16, > which is not understood by darwin: > > > /* Define float_t and double_t per C standard, ISO/IEC 9899:2011 7.12 2, > > taking advantage of GCC's __FLT_EVAL_METHOD__ (which a compiler may > > define anytime and GCC does) that shadows FLT_EVAL_METHOD (which a > > compiler must define only in float.h). > */ > > #if __FLT_EVAL_METHOD__ == 0 > > typedef float float_t; > > typedef double double_t; > > #elif __FLT_EVAL_METHOD__ == 1 > > typedef double float_t; > > typedef double double_t; > > #elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1 > > typedef long double float_t; > > typedef long double double_t; > > #else /* __FLT_EVAL_METHOD__ */ > > # error "Unsupported value of __FLT_EVAL_METHOD__." > > #endif /* __FLT_EVAL_METHOD__ */ > > > Is the use of __FLT_EVAL_METHOD__ set to 16 supposed to be portable across > all targets? Or is it linux-only, and should marked as such? > See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=100854 . > Thanks for any help you can give. > > FX
gcc-9-20211223 is now available
Snapshot gcc-9-20211223 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20211223/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision e08ac1a01b18076520c12ab0997dd59d6b0b7ad8 You'll find: gcc-9-20211223.tar.xzComplete GCC SHA256=3471eb642fd65261af439eb32fbddf9ad1b3ca395305e392f391392f2a1a5b20 SHA1=5b7d79c3d451206aced06b0dd6013c237debaf4b Diffs from 9-20211216 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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: _Float16-related failures on x86_64-apple-darwin
Hi, > See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=100854 . I found that, indeed, but what I struggle to see is: this behaviour of __FLT_EVAL_METHOD__ has been around for several years now, so why aren’t there more tests failing? I’m not sure what the fix should be, either. We could use fixinclude to make the darwin headers happy, but we don’t really have a macro to provide the right value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro. What should be the float_t and double_t types for FLT_EVAL_METHOD == 16? float and double, if I understand right? FX
Re: _Float16-related failures on x86_64-apple-darwin
> I’m not sure what the fix should be, either. We could use fixinclude to make
> the darwin headers happy, but we don’t really have a macro to provide the
> right value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro.
>
> What should be the float_t and double_t types for FLT_EVAL_METHOD == 16?
> float and double, if I understand right?
This is one possibility, assuming I am right about the types:
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 46e3b8c993a..bea85ef7367 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -1767,6 +1767,18 @@ fix = {
test_text = ""; /* Don't provide this for wrap fixes. */
};
+/* The darwin headers don't accept __FLT_EVAL_METHOD__ == 16.
+*/
+fix = {
+hackname = darwin_flt_eval_method;
+mach = "*-*-darwin*";
+files = math.h;
+select= "^#if __FLT_EVAL_METHOD__ == 0$";
+c_fix = format;
+c_fix_arg = "#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == 16";
+test_text = "#if __FLT_EVAL_METHOD__ == 0";
+};
+
/*
* Fix on Digital UNIX V4.0:
* It contains a prototype for a DEC C internal asm() function,
Sucks to have to fix headers… and we certainly can’t fix people’s code that may
depend on __FLT_EVAL_METHOD__ have well-defined values. So not convinced this
is the right approach.
FX
Re: _Float16-related failures on x86_64-apple-darwin
gcc define __FLT_EVAL_METHOD__ according to
builtin_define_with_int_value ("__FLT_EVAL_METHOD__",
c_flt_eval_method (true));
and guess we need to handle things like:
/* GCC only supports one interchange type right now, _Float16. If
we're evaluating _Float16 in 16-bit precision, then flt_eval_method
will be FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16. */
+ if (x == FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16
+ && x == y)
+return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT;
if (x == FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16)
return y;
I'm testing the patch but still need approval from related MAINTAINERs.
On Fri, Dec 24, 2021 at 7:15 AM FX via Gcc wrote:
>
> > I’m not sure what the fix should be, either. We could use fixinclude to
> > make the darwin headers happy, but we don’t really have a macro to provide
> > the right value. Like a __FLT_EVAL_METHOD_OLDSTYLE__ macro.
> >
> > What should be the float_t and double_t types for FLT_EVAL_METHOD == 16?
> > float and double, if I understand right?
>
> This is one possibility, assuming I am right about the types:
>
> diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
> index 46e3b8c993a..bea85ef7367 100644
> --- a/fixincludes/inclhack.def
> +++ b/fixincludes/inclhack.def
> @@ -1767,6 +1767,18 @@ fix = {
> test_text = ""; /* Don't provide this for wrap fixes. */
> };
>
> +/* The darwin headers don't accept __FLT_EVAL_METHOD__ == 16.
> +*/
> +fix = {
> +hackname = darwin_flt_eval_method;
> +mach = "*-*-darwin*";
> +files = math.h;
> +select= "^#if __FLT_EVAL_METHOD__ == 0$";
> +c_fix = format;
> +c_fix_arg = "#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == 16";
> +test_text = "#if __FLT_EVAL_METHOD__ == 0";
> +};
> +
> /*
> * Fix on Digital UNIX V4.0:
> * It contains a prototype for a DEC C internal asm() function,
>
>
> Sucks to have to fix headers… and we certainly can’t fix people’s code that
> may depend on __FLT_EVAL_METHOD__ have well-defined values. So not convinced
> this is the right approach.
>
> FX
--
BR,
Hongtao
