[Bug sanitizer/61875] New: ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Bug ID: 61875 Summary: ATRIBUTE_NONNULL macro error Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: parkch98 at gmail 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 When I tried to build below flags, I found a error to build gcc. CFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ CXXFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ XCFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ TCFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' \ GCJFLAGS='-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE ' \ ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --disable-bootstrap --enable-languages=c,c++,objc,fortran,obj-c++,go --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.9 --enable-ssp --disable-libssp --disable-libvtv --disable-plugin --with-bugurl=http://bugs.tizen.org/ --with-pkgversion=Tizen --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.9 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --disable-multilib --build=x86_64-tizen-linux --host=x86_64-tizen-linux make STAGE1_CFLAGS=-g 'BOOT_CFLAGS=-O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE' -j8 -l16 = The error is : libtool: compile: /opt/opensource/gcc/build/./gcc/xgcc -shared-libgcc -B/opt/opensource/gcc/build/./gcc -nostdinc++ -L/opt/opensource/gcc/build/x86_64-tizen-linux/libstdc++-v3/src -L/opt/opensource/gcc/build/x86_64-tizen-linux/libstdc++-v3/src/.libs -L/opt/opensource/gcc/build/x86_64-tizen-linux/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-tizen-linux/bin/ -B/usr/x86_64-tizen-linux/lib/ -isystem /usr/x86_64-tizen-linux/include -isystem /usr/x86_64-tizen-linux/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -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-tizen-linux -I../../../../libsanitizer/../libstdc++-v3/libsupc++ -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE -I ../../../../libsanitizer/../libbacktrace -I ../libbacktrace -I ../../../../libsanitizer/../include -include ../../../../libsanitizer/libbacktrace/backtrace-rename.h -g -O2 -g2 -feliminate-unused-debug-types -pipe -fexceptions --param=ssp-buffer-size=32 -Wformat -Wformat-security -fmessage-length=0 -march=corei7 -msse4.2 -mtune=corei7-avx -mfpmath=sse -fasynchronous-unwind-tables -fno-omit-frame-pointer -fipa-cp-clone -U_FORTIFY_SOURCE -D_GNU_SOURCE -MT sanitizer_symbolizer_libbacktrace.lo -MD -MP -MF .deps/sanitizer_symbolizer_libbacktrace.Tpo -c ../../../../libsanitizer/sanitizer_common/sanitizer_symbolizer_libbacktrace.cc -fPIC -DPIC -o .libs/sanitizer_symbolizer_libbacktrace.o In file included from
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #6 from Igor Zamyatin izamyatin at gmail dot com --- Eric, dou you have any plans regarding this issue?
[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- I think the error may be caused by compiling gcc with -fexceptions. Here is a short repro: $ cat tmp.cpp int f () throw (); int f (); $ g++ -fexceptions tmp.cpp -c tmp.cpp:2:8: error: declaration of ‘int f()’ has a different exception specifier tmp.cpp:1:5: error: from previous declaration ‘int f() throw ()’ The error is well known, here's link to Perl bug with proposed solution: https://rt.perl.org/Public/Bug/Display.html?id=121151
[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Marat Zakirov m.zakirov at samsung dot com changed: What|Removed |Added CC||m.zakirov at samsung dot com --- Comment #2 from Marat Zakirov m.zakirov at samsung dot com --- We had the same problem in Tizen. But my Q to asan and gcc maintainers is wider. Do we consider that asan in gcc should build with option -fexeptions? Or should it ignore this option? Or fail as it is for know?
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #24 from ktkachov at gcc dot gnu.org --- (In reply to Dodji Seketeli from comment #22) So finally the two patches that have been proposed at https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01063.html and https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01064.html have been accepted and committed to trunk. I'll wait before closing this bug that the stakeholders following this test the tree with the new patches. This breaks building ncurses. I've filed PR 61832 for this, but now trying to reduce a testcase. In the mean time, I'll look at the additional issue PR61817. Thanks.
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312 --- Comment #9 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #6) Marc, are you going to send your patch to the mailing list (CC Jason)? Sorry, I don't remember this patch at all. I may try again to understand what it does at some point, but you seem to have a much better understanding of what is going on, so don't hesitate to take this bug.
[Bug sanitizer/61875] ATRIBUTE_NONNULL macro error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61875 Tatiana Udalova t.udalova at samsung dot com changed: What|Removed |Added CC||t.udalova at samsung dot com --- Comment #3 from Tatiana Udalova t.udalova at samsung dot com --- You can fix problem in Tizen via deletting -fexceptions flag from the default flags for gcc, cross-gcc and cross-gcc-accel packages: OPT_FLAGS=`echo $OPT_FLAGS | sed -e 's/-fexceptions / /'`
[Bug c++/61867] gcc can't detect obviously false test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61867 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to David Binderman from comment #3) I think that all that needs to happen is a warning is produced where either the detection or reduction takes place. There is no single place, it's a result of constant propagation and a whole range of optimisations cooperating. Those optimisations are a good thing, you don't want to spit out a warning every time the compiler decides it can remove part of the code, you'd end up with either hundreds of warnings for correct code or disabling all optimisations. As ever, users are free to ignore warnings. egrep -v is useful, I find. egrep is useless for ignoring warnings. It might help on the command line, but not if you run the compiler from an editor or IDE, or with -Werror etc. Just because you don't mind ignoring warnings doesn't mean it is appropriate for GCC to start spitting out poor quality warnings.
[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 --- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com --- Hi Rainer, Could you try attached patch to check if it helps (test should not be run for sparc). Thanks ahead. Yuri.. 2014-07-16 19:20 GMT+04:00 ro at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 33128 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33128action=edit vect dump -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tree-optimization/61876] New: Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876
Bug ID: 61876
Summary: Converting __builtin_round + cast into
__builtin_lround is not always equivalent in regards
to math errno
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Consider code:
long int
foo (double a)
{
return __builtin_round (a);
}
With an aarch64-none-elf toolchain this compiles to:
foo:
fcvtas x0, d0
ret
whereas with an aarch64-linux toolchain this compiles to:
foo:
b lround
The linux (glibc) toolchain does not inline the lround implementation.
The suspicious starting point is this code in convert.c:
CASE_FLT_FN (BUILT_IN_ROUND):
/* Only convert in ISO C99 mode. */
if (!targetm.libc_has_function (function_c99_misc))
break;
if (outprec TYPE_PRECISION (integer_type_node)
|| (outprec == TYPE_PRECISION (integer_type_node)
!TYPE_UNSIGNED (type)))
fn = mathfn_built_in (s_intype, BUILT_IN_IROUND);
else if (outprec == TYPE_PRECISION (long_integer_type_node)
!TYPE_UNSIGNED (type))
fn = mathfn_built_in (s_intype, BUILT_IN_LROUND);
else if (outprec == TYPE_PRECISION (long_long_integer_type_node)
!TYPE_UNSIGNED (type))
fn = mathfn_built_in (s_intype, BUILT_IN_LLROUND);
break;
Basically it does the conversion of (cast to long int + round) == lround
But later on in builtins.c the lround does not get expanded into the sfix optab
unless -fno-math-errno is specified:
/* There's no easy way to detect the case we need to set EDOM. */
if (!flag_errno_math)
{
rtx result = gen_reg_rtx (mode);
/* Wrap the computation of the argument in a SAVE_EXPR, as we may
need to expand the argument again. This way, we will not perform
side-effects more the once. */
CALL_EXPR_ARG (exp, 0) = arg = builtin_save_expr (arg);
op0 = expand_expr (arg, NULL, VOIDmode, EXPAND_NORMAL);
start_sequence ();
if (expand_sfix_optab (result, op0, builtin_optab))
{
/* Output the entire sequence. */
insns = get_insns ();
end_sequence ();
emit_insn (insns);
return result;
}
I think if the cast+round - lround transformation is done it should be assumed
in that case that lround will not set errno.
Another approach would be to not do the transformation unless -fno-math-errno
[Bug middle-end/61876] Converting __builtin_round + cast into __builtin_lround is not always equivalent in regards to math errno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61876 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Component|tree-optimization |middle-end --- Comment #1 from ktkachov at gcc dot gnu.org --- This particular example is given for aarch64 but I imagine it could occur for any other target. From what I understand lround can potentially set errno on a domain error whereas round is valid everywhere and the cast to long int could be undefined behaviour if the double is not valid, but undefined behaviour is not the same as setting errno...
[Bug go/61877] New: [4.10 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 Bug ID: 61877 Summary: [4.10 Regression]: reflect: cannot use []string as type string in Call Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: go Assignee: ian at airs dot com Reporter: lists at kambanaria dot org CC: cmang at google dot com Created attachment 33171 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33171action=edit test case that can be executed with go test -compiler gccgo -test.v reflect_test There is a regression in the runtime behavior of the reflection module. Attached is a very simple ( 30 lines) test case (that can be execured via go test command). I hope this can be included in the normal test suite Expected behavior: go run -compiler gccgo src/ref_main.go go test -compiler gccgo -test.v reflect_test should result in: === RUN TestFindingVarargMethod --- PASS: TestFindingVarargMethod (0.00 seconds) PASS ok Actual behavior: === RUN TestFindingVarargMethod --- FAIL: TestFindingVarargMethod (0.00 seconds) panic: reflect: cannot use []string as type string in Call [recovered] panic: reflect: cannot use []string as type string in Call goroutine 20 [running]: testing.$nested5 ../.././libgo/go/testing/testing.go:406 reflect.call.N13_reflect.Value ../.././libgo/go/reflect/value.go:494 reflect.Call.N13_reflect.Value ../.././libgo/go/reflect/value.go:412 reflect.call.pN20_reflect.makeFuncImpl ../.././libgo/go/reflect/makefunc.go:198 reflect.MakeFuncStubGo ../.././libgo/go/reflect/makefuncgo_amd64.go:322 reflect_test_test.TestFindingVarargMethod /home/ashopov/WORK/GO/src/reflect_test/finder_test.go:19 testing.tRunner ../.././libgo/go/testing/testing.go:422 created by testing.RunTests ../.././libgo/go/testing/testing.go:504 goroutine 16 [chan receive]: testing.RunTests ../.././libgo/go/testing/testing.go:505 testing.Main ../.././libgo/go/testing/testing.go:435 main.main /tmp/go-build886615920/reflect_test/_test/_testmain.go:47 created by main ../.././libgo/runtime/go-main.c:42 goroutine 18 [finalizer wait]: created by runtime_createfing ../.././libgo/runtime/mgc0.c:2596 exit status 2 FAILreflect_test0.058s This test case is WORKING fine with: 1. golang-pkg-bin-linux-amd64-1.2.2-7 distributed with Fedora 20 which corresponds to 2. gcc 4.9: gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC/libexec/gcc/x86_64-linux-gnu/4.9.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../configure --prefix=/home/ashopov/WORK/GCC --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.9.1 20140709 (prerelease) (GCC) This test case is FAILING with: 1. gcc 4.10 gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC-TRUNK/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ./configure --prefix=/home/ashopov/WORK/GCC-TRUNK --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.10.0 20140721 (experimental) (GCC) Machine used for tests: uname -a Linux ashopov-dev 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[Bug go/61877] [4.10 Regression]: reflect: cannot use []string as type string in Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877 --- Comment #1 from Alexander Shopov lists at kambanaria dot org --- I will provide additional information if necessary
[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #3 from Yuri Rumyantsev ysrumyan at gmail dot com --- Hi Rainer, Could you try attached patch to check if it helps (test should not be run for sparc). Indeed, the test is UNSUPPORTED now. Thanks. Rainer
[Bug c++/61873] with -openmp, -E does not produce preprocessed output on stdout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61873 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Of course, because it's -fopenmp. -o specifies output file, in this case penmp.
[Bug c++/61870] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:1035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61870 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I can't reproduce it with 4.7 (that is not supported anymore), neither with 4.8. 4.9 and trunk reject this code.
[Bug tree-optimization/61822] gcc.dg/vect/vect-cond-reduc-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61822 --- Comment #5 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Tue Jul 22 12:53:04 2014 New Revision: 212911 URL: https://gcc.gnu.org/viewcvs?rev=212911root=gccview=rev Log: gcc/testsuite PR tree-optimization/61822 * gcc.dg/vect/cond-reduc-1.c: Add missed dg directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-1.c
[Bug libgcc/61752] on cygwin, aborts during exit() with a dynamically loaded C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752 --- Comment #2 from jon.turney at dronecode dot org.uk --- Better patch: https://cygwin.com/ml/cygwin/2014-07/msg00180.html
[Bug c/61878] New: Missing intrinsic functions in avx512intrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61878 Bug ID: 61878 Summary: Missing intrinsic functions in avx512intrin.h Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: agner at agner dot org A few compare functions are missing in avx512intrin.h, e.g. _mm512_cmpgt_epu32_mask and _mm512_cmpgt_epu64_mask All intrinsic functions for typecasting are also missing. Please add these functions, as they are indispensable. See https://software.intel.com/en-us/node/513903 and https://software.intel.com/sites/landingpage/IntrinsicsGuide/ for documentation of these functions. Definitions copied from Intel's zmmintrin.h: /* Conversion from one type to another, no change in value. */ extern __m512 __ICL_INTRINCC _mm512_castpd_ps(__m512d); extern __m512i __ICL_INTRINCC _mm512_castpd_si512(__m512d); extern __m512d __ICL_INTRINCC _mm512_castps_pd(__m512); extern __m512i __ICL_INTRINCC _mm512_castps_si512(__m512); extern __m512 __ICL_INTRINCC _mm512_castsi512_ps(__m512i); extern __m512d __ICL_INTRINCC _mm512_castsi512_pd(__m512i); * Casts from a larger type to a smaller type. */ extern __m128d __ICL_INTRINCC _mm512_castpd512_pd128(__m512d); extern __m128 __ICL_INTRINCC _mm512_castps512_ps128(__m512); extern __m128i __ICL_INTRINCC _mm512_castsi512_si128(__m512i); extern __m256d __ICL_INTRINCC _mm512_castpd512_pd256(__m512d); extern __m256 __ICL_INTRINCC _mm512_castps512_ps256(__m512); extern __m256i __ICL_INTRINCC _mm512_castsi512_si256(__m512i); /* * Casts from a smaller type to a larger type. * Upper elements of the result are undefined. */ extern __m512d __ICL_INTRINCC _mm512_castpd128_pd512(__m128d); extern __m512 __ICL_INTRINCC _mm512_castps128_ps512(__m128); extern __m512i __ICL_INTRINCC _mm512_castsi128_si512(__m128i); extern __m512d __ICL_INTRINCC _mm512_castpd256_pd512(__m256d); extern __m512 __ICL_INTRINCC _mm512_castps256_ps512(__m256); extern __m512i __ICL_INTRINCC _mm512_castsi256_si512(__m256i);
[Bug lto/53808] Undefined symbol when building a library with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 --- Comment #12 from Rafael Avila de Espindola rafael.espindola at gmail dot com --- Note that this bug is present once more when -fno-use-all-virtuals is used. With the original testcase gcc again produces an undefined reference to _ZN3barD0Ev. Is -fno-use-all-virtuals intended to be an abi breaking option? If so it would be nice to document that.
[Bug middle-end/61879] New: [4.10 Regression] GCC gives note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61879 Bug ID: 61879 Summary: [4.10 Regression] GCC gives note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com Target: i686-pc-linux-gnu Created attachment 33172 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33172action=edit Testcase GCC 4.10.0 20140720 (experimental). $ gcc -S -march=pentium4 -g -O2 -fpie bug.c bug.c: In function 'foo': bug.c:11:5: note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location int foo(int *p) ^ bug.c:11:5: note: non-delegitimized UNSPEC UNSPEC_GOTOFF (1) found in variable location Appeared in 210914 r = 211358.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #34 from paul.richard.thomas at gmail dot com paul.richard.thomas
at gmail dot com ---
Hi Dominique,
Should one be getting false? It seems to me that the code looks right.
within the do loop:
new_prt_spec ([string_t's]) produces an array of string_t's whose
char.data is null. It does nothing with the input array.
This output string is fed to process configuration, which does nothing
to it. This is surprising in itself :-)
Finally, your patch comes into play. This should do nothing if the
char.data's are null, which they should be.
Mystified
Paul
On 21 July 2014 21:56, dominiq at lps dot ens.fr
gcc-bugzi...@gcc.gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #33 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Dear Paul,
I cannot see yet, where it comes in nor when it was introduced.
Unfortunately I has been introduced by me, see comment 5. The code is
+ if (expr-ts.type == BT_DERIVED expr-rank
+ !gfc_is_finalizable (expr-ts.u.derived, NULL)
+ expr-ts.u.derived-attr.alloc_comp
+ expr-expr_type != EXPR_VARIABLE)
+{
+ tree tmp;
+
+ tmp = build_fold_indirect_ref_loc (input_location, se-expr);
+ tmp = gfc_deallocate_alloc_comp (expr-ts.u.derived, tmp, expr-rank);
+
+ /* The components shall be deallocated before
+ their containing entity. */
+ gfc_prepend_expr_to_block (se-post, tmp);
+}
Question: what condition should be added to the 'if' to get a false for
'expr-expr_type == EXPR_ARRAY' and an elemental function?
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug go/61880] New: Linking with external functions in C does not work in GO when using gccgo, while it works in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61880 Bug ID: 61880 Summary: Linking with external functions in C does not work in GO when using gccgo, while it works in gc Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: lists at kambanaria dot org CC: cmang at google dot com Created attachment 33173 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33173action=edit tiniest GOPATH demoing the problem (28 nonempty lines, 6 in C, 22 in GO including comments) This is continuation of issue reported here: https://code.google.com/p/gofrontend/issues/detail?id=36 Since I have changed the test case to be extremely simple with no external references to any libraries or applications, I am moving the bug here. 1. Demo of the issue: tar xvfz CGO_FALURE.tar.gz cd CGO_FALURE export GOPATH=`pwd` go run -compiler gccgo src/cgo_problem/demo.go results in: # command-line-arguments /tmp/go-build280712483/cgo_problem/example.com/libdemo.a(_cgo_export.o): In function `Dummy': /tmp/go-build280712483/cgo_problem/example.com/demo/_obj/_cgo_export.c:5: undefined reference to `cgo_problem_example_com_demo.Cgoexp_Dummy' collect2: error: ld returned 1 exit status 2. Compare with the behavior of gc: go run -compiler gccgo src/cgo_problem/demo.go results in: Address of function Dummy: 0x400f30 The issue can be worked around by renaming the example.com/demo package to example_com/demo mv src/cgo_problem/example.com src/cgo_problem/example.com sed -i 's/example[.]com/example_com/' src/cgo_problem/demo.go 3. The problem stems from: The _cgo_export.h file that is emitted by cgo. The first part of the name given to __asm__ macro is generated by the gccgoSymbolPrefix method here: http://golang.org/src/cmd/cgo/out.go#L985 Perhaps the runes that get emitted directly should include the dot '.' - it is the domain delimiter character which is reused in package names. 4. gcc versions 4.8, 4.9, 4.10 suffer from this issue: 4.8: COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC) 4.9: COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC/libexec/gcc/x86_64-linux-gnu/4.9.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../configure --prefix=/home/ashopov/WORK/GCC --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.9.1 20140709 (prerelease) (GCC) 4.10: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/ashopov/WORK/GCC-TRUNK/libexec/gcc/x86_64-linux-gnu/4.10.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ./configure --prefix=/home/ashopov/WORK/GCC-TRUNK --build=x86_64-linux-gnu --disable-browser-plugin --disable-libgcj --disable-libmudflap --disable-vtable-verify --disable-libunwind-exceptions --enable-checking=release --disable-bootstrap --enable-__cxa_atexit --enable-gnu-unique-object --enable-languages=c,c++,go,lto --enable-linker-build-id --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --with-linker-hash-style=gnu --with-system-zlib --with-tune=generic --enable-multiarch Thread model: posix gcc version 4.10.0 20140721 (experimental) (GCC) 5. System is: Linux ashopov-dev 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux - up to
[Bug c/61864] Feature Request, -Wcovered-switch-default to identify dead default branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug fortran/61881] New: ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881 Bug ID: 61881 Summary: ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*) Product: gcc Version: 4.10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: pault at gcc dot gnu.org The following code uses assumed-rank and CLASS(*) and ICEs. Such a code might get used for GCC's OpenACC implementation. foo.f90:3:0: internal compiler error: in fold_convert_loc, at fold-const.c:2074 call test(4) ^ 0x87556c fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2074 0x69f570 gfc_conv_intrinsic_to_class(gfc_se*, gfc_expr*, gfc_typespec) ../../gcc/fortran/trans-expr.c:592 program test implicit none call test(4) call test([4]) contains subroutine test(a) class(*), dimension(..) :: a end subroutine test end
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-22 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 --- Comment #14 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Jul 22 16:20:25 2014 New Revision: 212915 URL: https://gcc.gnu.org/viewcvs?rev=212915root=gccview=rev Log: 2014-07-22 Martin Jambor mjam...@suse.cz PR ipa/61160 * g++.dg/ipa/pr61160-3.C (main): Return zero. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ipa/pr61160-3.C
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #7 from Jan Hubicka hubicka at ucw dot cz --- Actually at the cauldron discussion I got an idea that it may be issue with anchor generation not bringing in all the constructors. Is the problem there that constructors of static vairables are empty in the final binary? Honza
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #7) Actually at the cauldron discussion I got an idea that it may be issue with anchor generation not bringing in all the constructors. Is the problem there that constructors of static vairables are empty in the final binary? yes.
[Bug c++/61882] New: attribute weak ignored for function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61882
Bug ID: 61882
Summary: attribute weak ignored for function templates
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gmail dot com
In GCC 4.5 and later, and at -O and above, attribute weak (but not weak alias)
is silently ignored on declarations of function templates and calls to
specializations of such templates are inlined into their callers.
The program below shows that GCC inlines calls to the function template
specialization instantiated from the weak primary template baz, but emits a
weak symbol for the weak alias fooint. GCC 4.2 honored the attribute and
emitted a weak symbol for both fooint and bazint. Clang 3.4 also emits a
weak symbol for both as expected. Disabling optimization changes the current
behavior to match that of GCC 4.2.1 and Clang 3.4.
The GCC documentation of attribute weak doesn't say whether or not the
attribute is intended to have the same effect on specializations of function
templates as it does on ordinary functions. If the current GCC behavior is
intended, the documentation should be updated to make it clear when attribute
weak is ignored, and GCC should be enhanced to issue a warning when the
attribute is ignored.
$ (set -x; cc=/auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++; cat z.c
$cc -c -fpic -DFOO=1 -O -Wall -Wextra z.c $cc -fpic -Wall -Wextra z.c z.o
./a.out)
+ cc=/auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++
+ cat z.c
template class T void foo (T);
template class T void baz (T);
void foobar ();
#if FOO
template class T void __attribute__ ((weak, alias (bar))) foo (T);
static void bar (int) { }
template class T void __attribute__ ((weak)) baz (T) { }
void foobar () { foo (0), baz (0); }
#else
# include stdio.h
template void foo (int) { puts (__func__); }
template void baz (int) { puts (__func__); }
int main (void) { foobar (); }
#endif
+ /auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++ -c -fpic -DFOO=1 -O -Wall
-Wextra z.c
+ /auto/compiler-dev/msebor/contrib/cel-5.50/bin/g++ -fpic -Wall -Wextra z.c
z.o
+ ./a.out
fooint
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Eric, dou you have any plans regarding this issue? Sure, see comment #3.
[Bug c/61579] -Wwrite-strings does not behave as a warning option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61579 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. I might possibly get to this.
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Seems that the location of __FILE__ is generally broken, e.g. on
extern void foo (int i);
void
f (void)
{
foo (__FILE__);
}
the column info is wrong as well.
[Bug fortran/61881] ICE in gfc_conv_intrinsic_to_class with assumed-rank CLASS(*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61881 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- After deletion the line program test I get the ICE which at the same place as the tests in pr49802 comments 5 and 8.
[Bug testsuite/61748] imm-devirt-2.C failed on arm-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61748 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Component|middle-end |testsuite Resolution|--- |FIXED --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- Fixed by [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01417.html
[Bug target/61878] Missing intrinsic functions in avx512intrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61878 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-22 CC||kyukhin at gcc dot gnu.org Target Milestone|--- |4.9.2 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Confirmed.
[Bug testsuite/61826] [4.10 regression] gcc.dg/pr44024.c UNRESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61826 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|middle-end |testsuite Resolution|--- |FIXED --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Fixed by [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01417.html
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #8 from Tom Tromey tromey at gcc dot gnu.org --- You don't need a typedef: int x; int g(x); 137: Abbrev Number: 2 (DW_TAG_variable) 38 DW_AT_name: g 3a DW_AT_decl_file : 1 3b DW_AT_decl_line : 2 3c DW_AT_type: 0x4a 40 DW_AT_external: 1 40 DW_AT_location: 9 byte block: 3 0 0 0 0 0 0 0 0 (DW_OP_addr: 0) 14a: Abbrev Number: 4 (DW_TAG_const_type) 4b DW_AT_type: 0x4f [...]
[Bug c/61861] Incorrect column number for -Wdiscarded-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61861 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- The same for __DATE__, __TIME__, __LINE__.
[Bug target/61883] New: [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883
Bug ID: 61883
Summary: [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm
target
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tony.wang at arm dot com
The trunk will ICE when user declare tls variables with alias name on run-time
need to generate emutls variables.
How to reproduce:
/work/tonwan01/test_alias$
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/install-native/lib/gcc/arm-none-eabi/4.10.0/cc1
-quiet -v -D_USES_INITFINI_ alias-1-clean.c -quiet -dumpbase alias-1-clean.c
-mthumb -mcpu=cortex-m0 -auxbase-strip alias-1.exe -version -o /tmp/cc0AHQ0g.s
alias-1.c:24:3: internal compiler error: Segmentation fault
_attribute_ ((visibility (hidden)));
^
0xbdde7f crash_signal
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/toplev.c:337
0x78b390 symtab_alias_target
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraph.h:1535
0x78d629 verify_symtab_base(symtab_node*)
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:830
0x78d7bb verify_symtab_node(symtab_node*)
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:863
0x78d823 verify_symtab()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/symtab.c:881
0x9e6e85 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/ipa.c:592
0x7a09f3 ipa_passes
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2065
0x7a0d70 compile()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2187
0x7a107c finalize_compilation_unit()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/cgraphunit.c:2342
0x60ba71 c_write_global_declarations()
/work/tonwan01/gcc/gcc-arm-none-eabi-4_9-2014q2-20140515/src/gcc/gcc/c/c-decl.c:10452
The reason for this bug is that in the tree-emutls.c pass, the code imply a
default sequence of tls symbol and its corresponding control symbol. Some patch
now move the symtab node generation to a very early stage, so the sequence of
the node in varpool changed which leads to the wrong mapping of tls var and
control var.
For case gcc.dg/tls/alias-1.c
Before:
tls_vars[0]:bar(alias foo)
tls_vars[1]:foo
control_vars[0]:_emutls_v.foo
control_vars[1]:_emutls_v.bar(alias _emutls_v.foo)
So when generate the reference list of main, the actual reference of bar would
be _emutls_v.foo which is correct.
After:
tls_vars[1]:bar(alias foo)
tls_vars[0]:foo
control_vars[0]:_emutls_v.foo
control_vars[1]:_emutls_v.bar(alias _emutls_v.foo)
The reference list of main will point to the alias symbol node _emutls_v.bar,
which finally cause the segment fault.
I also a simpler test case to reproduce this bug, it should be an old bug for
the tree-emutls pass. The way this pass mapping the control vars and tls vars
hasn't consider that there may more than one alias for a tls var. For run time
support tls, the code can compile successfully.
struct __res_state {
char x[123];
};
__thread struct __res_state foo;
extern __thread struct __res_state bar
__attribute__ ((alias (foo)));
extern __thread struct __res_state baz
__attribute__ ((alias (foo)));
int main()
{
bar.x[0] = 0;
baz.x[1] = 1;
return 0;
}
[Bug target/61883] [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883 --- Comment #1 from wangzheyu tony.wang at arm dot com --- For target don't support tls, the above simple test case will fail for the same reason of gcc.dg/tls/alias-1.c.
[Bug regression/61548] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 61883 has been marked as a duplicate of this bug. ***
[Bug target/61883] [4.10 Regression]ICE for gcc.dg/tls/alias-1.c on arm target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61883 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 61548. *** This bug has been marked as a duplicate of bug 61548 ***
[Bug regression/61548] [4.10 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0 Summary|FAIL: gcc.dg/tls/alias-1.c |[4.10 Regression] FAIL: |(internal compiler error) |gcc.dg/tls/alias-1.c ||(internal compiler error)
[Bug regression/61548] [4.10 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548
--- Comment #7 from wangzheyu tony.wang at arm dot com ---
I have a simpler test case to reproduce this bug, it should be an old bug for
the tree-emutls pass. The way this pass mapping the control vars and tls vars
hasn't consider that there may more than one alias for a tls var. For target
supports tls, the code can compile successfully, but the target doesn't support
tls will fail.
struct __res_state {
char x[123];
};
__thread struct __res_state foo;
extern __thread struct __res_state bar
__attribute__ ((alias (foo)));
extern __thread struct __res_state baz
__attribute__ ((alias (foo)));
int main()
{
bar.x[0] = 0;
baz.x[1] = 1;
return 0;
}
