[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770 --- Comment #25 from 康 珊 --- (In reply to rguent...@suse.de from comment #24) > On September 22, 2020 1:14:48 PM GMT+02:00, kangshan0910 at hotmail dot com > wrote: > >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770 > > > >--- Comment #23 from 康 珊 --- > >It seems that gcc will use "_ZGVeN8vl8l8_sincos" which doesn't exit in > >libmvec. > >/usr/bin/ld: /tmp/ccTYyEZM.o: in function `main': > >/home/pnp/ks/test_sincos.c:38: undefined reference to > >`_ZGVeN8vl8l8_sincos' > >/usr/bin/ld: /home/pnp/ks/test_sincos.c:38: undefined reference to > >`_ZGVeN8vl8l8_sincos' > >collect2: error: ld returned 1 exit status > > That's expected and the thing that needs to be fixed. > > >I'm using clear linux the glibc of which is 2.31 and I also tried > >Ubuntu 19.10 > >the glibc of which is 2.30. But it has _ZGVeN8vvv_sincos(__m512d, __m512i, __m512i), why gcc not use this call?
[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770 --- Comment #23 from 康 珊 --- It seems that gcc will use "_ZGVeN8vl8l8_sincos" which doesn't exit in libmvec. /usr/bin/ld: /tmp/ccTYyEZM.o: in function `main': /home/pnp/ks/test_sincos.c:38: undefined reference to `_ZGVeN8vl8l8_sincos' /usr/bin/ld: /home/pnp/ks/test_sincos.c:38: undefined reference to `_ZGVeN8vl8l8_sincos' collect2: error: ld returned 1 exit status I'm using clear linux the glibc of which is 2.31 and I also tried Ubuntu 19.10 the glibc of which is 2.30.
[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770
--- Comment #21 from 康 珊 ---
(In reply to Jakub Jelinek from comment #15)
> OpenMP has a way to express this,
> #pragma omp declare simd notinbranch linear(y,z)
> double sincos (double x, double *y, double *z);
> As can be seen on -O2 -fopenmp-simd:
> #pragma omp declare simd notinbranch linear(y, z)
> double foo (double x, double *y, double *z);
>
> double a[1024], b[1024], c[1024];
>
> void
> bar (void)
> {
> #pragma omp simd
> for (int i = 0; i < 1024; i++)
> foo (a[i], &b[i], &c[i]);
> }
> it works fine with that. But if #pragma omp simd is commented out, it is
> not, because the compiler has no assurance on what the function call
> behavior will be e.g. for data reference analysis (it could e.g. modify the
> global vars).
> Now, for sincos proper, the compiler knows what the function does if not
> -fno-builtin-sincos.
>
> Unfortunately, I think glibc currently defines sincos in math-vector.h the
> unuseful way with just simd ("notinbranch") attribute, which effectively
> means
> that the caller is supposed to pass vectors of pointers (well integers with
> those sizes) and so needs scatter under the hood.
> So the best thing would be to change glibc first.
Thanks for your reply.(In reply to Jakub Jelinek from comment #15)
> OpenMP has a way to express this,
> #pragma omp declare simd notinbranch linear(y,z)
> double sincos (double x, double *y, double *z);
> As can be seen on -O2 -fopenmp-simd:
> #pragma omp declare simd notinbranch linear(y, z)
> double foo (double x, double *y, double *z);
>
> double a[1024], b[1024], c[1024];
>
> void
> bar (void)
> {
> #pragma omp simd
> for (int i = 0; i < 1024; i++)
> foo (a[i], &b[i], &c[i]);
> }
> it works fine with that. But if #pragma omp simd is commented out, it is
> not, because the compiler has no assurance on what the function call
> behavior will be e.g. for data reference analysis (it could e.g. modify the
> global vars).
> Now, for sincos proper, the compiler knows what the function does if not
> -fno-builtin-sincos.
>
> Unfortunately, I think glibc currently defines sincos in math-vector.h the
> unuseful way with just simd ("notinbranch") attribute, which effectively
> means
> that the caller is supposed to pass vectors of pointers (well integers with
> those sizes) and so needs scatter under the hood.
> So the best thing would be to change glibc first.
Thanks for your reply. I tried your method. But it still doesn't work for
sincos.
#pragma omp declare simd notinbranch linear(y, z)
void sincos(double x, double *y, double *z);
for (unsigned int i = 0; i < loopCount; i++)
{
#pragma omp simd
for (unsigned int j = i * dim; j < (i + 1) * dim; j++)
{
sincos(input_array[j], &result_array[j], &result_array1[j]);
}
}
$ gcc -m64 -g -O2 -fopenmp-simd -fPIC -Wall test_sincos.c -o test_sincos -lm
-march=skylake-avx512 -ffast-math -ftree-loop-vectorize
$ ldd test_sincos
linux-vdso.so.1 (0x7ffd2393f000)
libm.so.6 => /lib64/libm.so.6 (0x7f574f49d000)
libc.so.6 => /lib64/libc.so.6 (0x7f574f2a2000)
/lib64/ld-linux-x86-64.so.2 (0x7f574f601000)
My gcc version is "10.1.1 20200507".
And I have uploaded my test source file.
[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770 --- Comment #20 from 康 珊 --- Created attachment 49255 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49255&action=edit test source file
[Bug tree-optimization/40770] Vectorization of complex types, vectorization of sincos missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770 --- Comment #13 from 康 珊 --- (In reply to Richard Biener from comment #12) > *** Bug 97149 has been marked as a duplicate of this bug. *** Will you look at this?
[Bug c/97149] sincos failed to be vectorized by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97149 康 珊 changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #3 from 康 珊 --- (In reply to Richard Biener from comment #2) > dup > > *** This bug has been marked as a duplicate of bug 40770 *** 40770 was reported about 11 years ago. It seems that it hasn't been fixed yet, right?
[Bug c/97149] sincos failed to be vectorized by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97149 --- Comment #1 from 康 珊 --- Created attachment 49247 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49247&action=edit test source code
[Bug c/97149] New: sincos failed to be vectorized by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97149
Bug ID: 97149
Summary: sincos failed to be vectorized by gcc
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kangshan0910 at hotmail dot com
Target Milestone: ---
My code pattern is:
for (unsigned int i = 0; i < loopCount; i++)
{
for (unsigned int j = i * dim; j < (i + 1) * dim; j++)
{
sincos(input_array[j], &result_arrays[j], &result_arrayc[j]);
}
}
And I compiled the code with the following options:
gcc -m64 -g -O2 -fPIC -Wall test_sincos.c -o test_sincos -lm
-march=skylake-avx512 -ffast-math -ftree-loop-vectorize
$ ldd test_sincos
linux-vdso.so.1 (0x7ffd2393f000)
libm.so.6 => /lib64/libm.so.6 (0x7f574f49d000)
libc.so.6 => /lib64/libc.so.6 (0x7f574f2a2000)
/lib64/ld-linux-x86-64.so.2 (0x7f574f601000)
You can find the the libmvec.so is not linked. I tried other functions such as
sin, cos, log... with the same code pattern and they can be vectorized by gcc.
But sincos cannot. Is there anything I missed?
My gcc version is "10.1.1 20200507".
[Bug sanitizer/94139] GCC9.2.0 build GCC8.2.0 break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94139 --- Comment #2 from 康 珊 --- This is a benchmark from phoronix (https://openbenchmarking.org/test/pts/build-gcc-1.1.2). The benchmark uses gcc-8.2.0.
[Bug sanitizer/94139] New: GCC9.2.0 build GCC8.2.0 break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94139 Bug ID: 94139 Summary: GCC9.2.0 build GCC8.2.0 break Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: kangshan0910 at hotmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Gcc8.2.0 will fail to be built after glibc is updated from 2.30 to 2.31. Here is the reproduce steps: 1. Download gcc-8.2.0 source code from ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-8.2.0/gcc-8.2.0.tar.gz or ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-8.2.0/gcc-8.2.0.tar.gz or https://ftp.gnu.org/gnu/gcc/gcc-8.2.0/gcc-8.2.0.tar.gz 2. Unzip the package #cd gcc-8.2.0 #./contrib/download_prerequisites #./configure --disable-multilib --enable-checking=release #make defconfig #make clean #make -j4 After a while, the following error will occur. /home/pnp/.phoronix-test-suite/installed-tests/pts/build-gcc-1.1.2/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc/xgcc -shared-libgcc -B/home/pnp/.phoronix-test-suite/installed-tests/pts/build-gcc-1.1.2/gcc-8.2.0/host-x86_64-pc-linux-gnu/gcc -nostdinc++ -L/home/pnp/.phoronix-test-suite/installed-tests/pts/build-gcc-1.1.2/gcc-8.2.0/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/pnp/.phoronix-test-suite/installed-tests/pts/build-gcc-1.1.2/gcc-8.2.0/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/pnp/.phoronix-test-suite/installed-tests/pts/build-gcc-1.1.2/gcc-8.2.0/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=1 -DHAVE_TIRPC_RPC_XDR_H=1 -I. -I../../.././libsanitizer/sanitizer_common -I.. -I ../../.././libsanitizer/include -isystem ../../.././libsanitizer/include/system -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-pc-linux-gnu -I../../.././libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../.././libsanitizer/../libbacktrace -I ../libbacktrace -I ../../.././libsanitizer/../include -include ../../.././libsanitizer/libbacktrace/backtrace-rename.h -O2 -g -O3 -feliminate-unused-debug-types -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=32 -Wformat -Wformat-security -m64 -fasynchronous-unwind-tables -Wp,-D_REENTRANT -ftree-loop-distribute-patterns -Wl,-z -Wl,now -Wl,-z -Wl,relro -fno-semantic-interposition -ffat-lto-objects -fno-trapping-math -Wl,-sort-common -Wl,--enable-new-dtags -mtune=skylake -Wa,-mbranches-within-32B-boundaries -fvisibility-inlines-hidden -Wl,--enable-new-dtags -D_GNU_SOURCE -MT sanitizer_platform_limits_posix.lo -MD -MP -MF .deps/sanitizer_platform_limits_posix.Tpo -c ../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -fPIC -DPIC -o .libs/sanitizer_platform_limits_posix.o In file included from ../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:193: ../../.././libsanitizer/sanitizer_common/sanitizer_internal_defs.h:317:72: error: size of array ‘assertion_failed__1152’ is negative typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1] ^ ../../.././libsanitizer/sanitizer_common/sanitizer_internal_defs.h:311:30: note: in expansion of macro ‘IMPL_COMPILER_ASSERT’ #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) ^~~~ ../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h:1475:3: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(sizeof(((__sanitizer_##CLASS *) NULL)->MEMBER) == \ ^~ ../../.././libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:1152:1: note: in expansion of macro ‘CHECK_SIZE_AND_OFFSET’ CHECK_SIZE_AND_OFFSET(ipc_perm, mode); ^ My debug environment is Clear Linux 32530, its default glibc is 2.31.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #33 from 康 珊 ---
(In reply to Martin Liška from comment #32)
> I can confirm it works for me with:
>
> diff --git a/common.gypi b/common.gypi
> index 9502e92..3d8f04f 100644
> --- a/common.gypi
> +++ b/common.gypi
> @@ -195,8 +195,8 @@
> 'ldflags': ['<(pgo_use)'],
>},],
>['enable_lto=="true"', {
> -'cflags': ['<(lto)'],
> -'ldflags': ['<(lto)'],
> +'cflags': ['<(lto) -fno-strict-aliasing'],
> +'ldflags': ['<(lto) -fno-strict-aliasing'],
>},],
> ],
>},],
It seems your solution works. But it doesn't work if I add
"-fno-strict-aliasing" through 'export CFLAGS="$CFLAGS -O3
-fno-strict-aliasing..." export CXXFLAGS="$CXXFLAGS -O3
-fno-strict-aliasing..." ...', maybe they are overridden. Thank you very much
for your help.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #30 from 康 珊 --- (In reply to Martin Liška from comment #29) > > Thanks for your reminder. Currently I found there were 3 ways to solve the > > issue. > > 1.Remove “enable-lto” in configure and open “fno-strict-aliasing”. > > 2.Add “__attribute__((noipa))” to the uv_unref(uv_handle_t*) function. > > 3.Add “__attribute__((noinline))” to the uv_unref(uv_handle_t*) function. > > Maybe the first solution is a more reliable one in contrast to the other two > > solutions. As solution 2 and 3 are more likely a workaround. Do you have any > > suggestions? > > It's always needed to use -fno-strict-aliasing as mentioned here: > https://github.com/nodejs/node/issues/27054 > > and the using --enable-lto should be fine. But if using "--enable-lto" and "-fno-strict-aliasing", the issue cannot be solved. In order to solve the issue, besides those options, “__attribute__((noipa))” has to be added to the uv_unref(uv_handle_t*) function. So you recommend this solution, right?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #28 from 康 珊 ---
(In reply to Martin Liška from comment #27)
> (In reply to 康 珊 from comment #26)
> > I found the previous build log is like "g++ -o
> > /builddir/build/BUILD/node-v10.15.3/out/Release/cctest -pthread -rdynamic
> > -m64
> > -Wl,--whole-archive,/builddir/build/BUILD/node-v10.15.3/out/Release/obj.
> > target/deps/uv/libuv.a -Wl,--no-whole-archive -Wl,-z,noexecstack
> > -Wl,--whole-archive
> > /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/deps/v8/gypfiles/
> > libv8_base.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,-T
> > /builddir/build/BUILD/node-v10.15.3/src/large_pages/ld.implicit.script
> > -pthread -flto=4 -fuse-linker-plugin -ffat-lto-objects -fno-lto
> > -Wl,--start-group
> > /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/cctest/test/
> > cctest/node_test_fixture.o...", you mean link options like "-flto=4
> > -ffat-lto-objects -fno-lto" are not accurate and "-fno-lto" will not take
> > effect, right?
>
> It will take effect, but you defined that only in LDFLAGS.
> Anyway, please don't use --enable-lto with {LD,C,CXX}FLAGS="${LDFLAGS}
> -fno-lto"!
Thanks for your reminder. Currently I found there were 3 ways to solve the
issue.
1.Remove “enable-lto” in configure and open “fno-strict-aliasing”.
2.Add “__attribute__((noipa))” to the uv_unref(uv_handle_t*) function.
3.Add “__attribute__((noinline))” to the uv_unref(uv_handle_t*) function.
Maybe the first solution is a more reliable one in contrast to the other two
solutions. As solution 2 and 3 are more likely a workaround. Do you have any
suggestions?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #26 from 康 珊 --- I found the previous build log is like "g++ -o /builddir/build/BUILD/node-v10.15.3/out/Release/cctest -pthread -rdynamic -m64 -Wl,--whole-archive,/builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/deps/uv/libuv.a -Wl,--no-whole-archive -Wl,-z,noexecstack -Wl,--whole-archive /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/deps/v8/gypfiles/libv8_base.a -Wl,--no-whole-archive -Wl,-z,relro -Wl,-z,now -Wl,-T /builddir/build/BUILD/node-v10.15.3/src/large_pages/ld.implicit.script -pthread -flto=4 -fuse-linker-plugin -ffat-lto-objects -fno-lto -Wl,--start-group /builddir/build/BUILD/node-v10.15.3/out/Release/obj.target/cctest/test/cctest/node_test_fixture.o...", you mean link options like "-flto=4 -ffat-lto-objects -fno-lto" are not accurate and "-fno-lto" will not take effect, right?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #25 from 康 珊 --- OK. Then I will remove "enable-lto" in configure and try "-O3" with "-fno-strict-aliasing" to see whether it can solve the issue.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #23 from 康 珊 ---
(In reply to Martin Liška from comment #22)
> (In reply to 康 珊 from comment #21)
> > All of the experiments were did in according to the build steps I just gave
> > to you.
>
> I'm sorry, but I would like to know whether you are talking about LTO builds
> (w/ --enable-lto in configure) or not? You tried both, so I'm curious which
> have you used?
It is configured with "--enable-lto" and LDFLAGS="${LDFLAGS} -fno-lto", I'm not
sure whether lto takes effect or not. Do you need me remove "enable-lto" in
configure and try the experiments?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #21 from 康 珊 --- All of the experiments were did in according to the build steps I just gave to you.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #19 from 康 珊 --- I tried the following experiments: 1)Tried "__attribute__((noinline)) uv_unref(uv_handle_t*)", it could solve the issue. 2)Tried "__attribute__((noipa)) uv_unref(uv_handle_t*)", it could solve the issue. 2)Tried "-O2", it could not solve the issue. 3)Tried "-O2 -fno-strict-aliasing", it could not solve the issue. 4)Tried "-O3 -fno-strict-aliasing", it could not solve the issue.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #18 from 康 珊 --- Sorry, actually I don't know the reason, and I failed to find any git comment for that configuration. It is involved from 10.14.2 build.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #16 from 康 珊 ---
OK. Our latest release nodejs package build steps are:
export CFLAGS="$CFLAGS -O3 -falign-functions=32 -fno-math-errno
-fno-semantic-interposition -fno-trapping-math "
export CXXFLAGS="$CXXFLAGS -O3 -falign-functions=32 -fno-math-errno
-fno-semantic-interposition -fno-trapping-math "
export PYTHON=/usr/bin/python2
./configure --prefix=/usr --shared-openssl --shared-zlib --use-largepages
--enable-lto --shared-nghttp2
export LDFLAGS="${LDFLAGS} -fno-lto"
export CFLAGS="$CFLAGS -O3 -falign-functions=32 -fno-math-errno
-fno-semantic-interposition -fno-trapping-math "
export FCFLAGS="$CFLAGS -O3 -falign-functions=32 -fno-math-errno
-fno-semantic-interposition -fno-trapping-math "
export FFLAGS="$CFLAGS -O3 -falign-functions=32 -fno-math-errno
-fno-semantic-interposition -fno-trapping-math "
export CXXFLAGS="$CXXFLAGS -O3 -falign-functions=32 -fno-math-errno
-fno-semantic-interposition -fno-trapping-math "
make -j4
The node source code URL is
https://nodejs.org/dist/v10.15.3/node-v10.15.3.tar.xz.
The GCC used is 8.3.1 20190228 gcc-8-branch@269272.
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #14 from 康 珊 ---
Yes, I built it with LDFLAGS="${LDFLAGS} -fno-lto". Moreover, I tried
"__attribute__((noipa)) uv_unref(uv_handle_t*);" and it could solve the issue.
So it may not be caused by the alias, right?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893
--- Comment #12 from 康 珊 ---
Yes, I built it with LDFLAGS="${LDFLAGS} -fno-lto". Moreover, I tried
"__attribute__((noipa)) uv_unref(uv_handle_t*);" and it could solve the issue.
So it may not be caused by the alias, right?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #10 from 康 珊 --- Hi Martin Liška, I tried to build it with "-O3 -fno-strict-aliasing -falign-functions=32 -fno-math-errno -fno-semantic-interposition -fno-trapping-math", but it still had the issue. Can "-fno-strict-aliasing" work normally with "-O3"?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #9 from 康 珊 --- That's great! Thank you very much for your support :)
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #7 from 康 珊 --- Thanks Martin Liška for your quick response. I'm sorry I'm not familiar with unique_ptr neither. Do you mean it is caused by the "Node" source logic itself?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #2 from 康 珊 --- Created attachment 46062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46062&action=edit octane benchmark part2
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #1 from 康 珊 --- Created attachment 46061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46061&action=edit octane benchmark part1
