[Bug middle-end/71473] [5/6/7 Regression] cilkplus sum reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473
--- Comment #6 from tprince at computer dot org ---
__sec_reduce_{min,max}_ind in Intel cilk(tm) plus don't give good performance,
so one may suspect they are using size_t.(In reply to Jakub Jelinek from
comment #5)
> While this started with my commit, the actual bug is there from the start of
> Cilk+ support.
> The __sec_reduce_* builtins are declared with int return type, which doesn't
> actual match what they return (it is in this case the type of the argument).
> I bet the current way to deal with this is handle those in
> resolve_overloaded_builtin and turn them into internal functions or
> something similar and resolve the return type at that point.
> The question is what to do with templates if the arguments are type
> dependent.
> Another thing that is weird is that the __sec_reduce_{min,max}_ind return
> int, I would have expected size_t or something more appropriate for array
> indexes. Does Cilk+ really mandate int in that case? How can it be used on
> a very large array then?
[Bug libstdc++/77814] build fails trying to build eh_arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77814 --- Comment #6 from tprince at computer dot org --- Permits bootstrap to proceed, will post to testresults when successful. Thanks.
[Bug libstdc++/77814] New: build fails trying to build eh_arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77814
Bug ID: 77814
Summary: build fails trying to build eh_arm
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tprince at computer dot org
Target Milestone: ---
Created attachment 39729
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39729=edit
log from trunk stage 1 bootstrap of libstdc++
Initial bootstrap tries (and fails) to build eh_arm.
/cygdrive/c/users/tim/tim/tim/src/gnu/gcc2/libstdc++-v3/include/bits/std_abs.h:
In function ‘long long int std::abs(long long int)’:
/cygdrive/c/users/tim/tim/tim/src/gnu/gcc2/libstdc++-v3/include/bits/std_abs.h:5
9:3: error: conflicting declaration of C function ‘long long int std::abs(long
l
ong int)’
abs(long long __x) { return __builtin_llabs (__x); }
^~~
full log attached
Guessing that the build shouldn't require this compilation.
[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 --- Comment #8 from tprince at computer dot org --- I show my configure parameters in my test results posts. At some time in the past, each of them has been important. I don't know if the parameters quoted by cygwin release pertain to cross compiling. As the parameters I use have been successful again last week on win8.1 I don't see how they might pertain to the f951 bootstrap failure on win10. When I get back to the win10 box I will compare with disable bootstrap.
[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 --- Comment #4 from tprince at computer dot org --- Same failure of f951 after checking alternate svn apps.
[Bug bootstrap/77593] [7 Regression] Bootstrap failure with configure-target-libgfortran " cygwin64 Windows 10 anniversary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 --- Comment #2 from tprince at computer dot org --- I suspect the Windows 10 provided svn may be partly at fault (although it works for bootstrapping on the Microsoft provided gcc in linux subsystem). I grabbed trunk using cygwin svn and have seen the bootstrap go as far as the stage3 libstdc++ build (without intervention) before jumping back to stage1 and failing on permissions to move into stage1-gcc.
[Bug fortran/77593] New: configure-target-libgfortran " cygwin64 Windows 10 anniversary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77593 Bug ID: 77593 Summary: configure-target-libgfortran " cygwin64 Windows 10 anniversary Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Target Milestone: --- Created attachment 39621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39621=edit Log file as specified in "please report a bug" This failure appears to be Windows version dependent, but it provokes "please report a bug." It's possible to cd into libgfortran and configure and build, but the gfortran build is faulty as the script reports. Attaching config.log as requested.
[Bug c/71473] cilkplus sum reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473 --- Comment #2 from tprince at computer dot org --- Created attachment 38669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38669=edit C include file
[Bug c/71473] cilkplus sum reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473 --- Comment #1 from tprince at computer dot org --- Created attachment 38668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38668=edit cilkplus C source (before preprocessing)
[Bug c/71473] New: cilkplus sum reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71473 Bug ID: 71473 Summary: cilkplus sum reducer ICE Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Target Milestone: --- Created attachment 38667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38667=edit cilkplus C source gcc 5.3 does not ICE on this case but run-time result is wrong. gcc -fcilkplus -std=c99 -c s176.i
[Bug libstdc++/69266] bootstrap failure undefined reference to `std::basic_ios<char, std::char_traits >::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69266 --- Comment #9 from tprince at computer dot org --- Trunk on 2016-01-29 is bootstrapping successfully, after dealing with the reluctance of the build to update config.cache in several directories (gcc, libcpp, libstdc++-v3, libgomp). Although I didn't see notification of how it was fixed, it looks like this PR could be closed.
[Bug libstdc++/69266] bootstrap failure undefined reference to `std::basic_ios<char, std::char_traits >::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69266 --- Comment #4 from tprince at computer dot org --- This works only when building libstdc++ with an older g++ version.
[Bug libstdc++/69266] bootstrap failure undefined reference to `std::basic_ios<char, std::char_traits >::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69266 --- Comment #2 from tprince at computer dot org --- It is possible to bootstrap by configure --disable-libstdcxx. Then it is possible to configure and build (but not make check?) in libstdc++-v3. I'm not sure of the consequences of this.
[Bug c++/69266] New: bootstrap failure undefined reference to `std::basic_ios<char, std::char_traits >::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69266 Bug ID: 69266 Summary: bootstrap failure undefined reference to `std::basic_ios<char, std::char_traits >:: Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Target Milestone: --- libtool: link: /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/./gcc/xgcc -sha red-libgcc -B/cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/./gcc -nostdinc++ -L/cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/x86_64-unknown-cygwin/libstdc ++-v3/src -L/cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/x86_64-unknown-cygw in/libstdc++-v3/src/.libs -L/cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/x86 _64-unknown-cygwin/libstdc++-v3/libsupc++/.libs -B/usr/local/gcc6.0/x86_64-unkno wn-cygwin/bin/ -B/usr/local/gcc6.0/x86_64-unknown-cygwin/lib/ -isystem /usr/loca l/gcc6.0/x86_64-unknown-cygwin/include -isystem /usr/local/gcc6.0/x86_64-unknown -cygwin/sys-include-shared -nostdlib /cygdrive/c/users/tim/tim/tim/src/gnu/g cc1/cyg64/./gcc/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_lis t.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compati bility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chr ono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libs upc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/l ibc++11convenience.a -Wl,--no-whole-archive -L/cygdrive/c/users/tim/tim/tim/src /gnu/gcc1/cyg64/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs -L/cygdrive/c /users/tim/tim/tim/src/gnu/gcc1/cyg64/x86_64-unknown-cygwin/libstdc++-v3/src -L/ cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/x86_64-unknown-cygwin/libstdc++- v3/src/.libs -L/usr/lib/w32api -L/cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg6 4/./gcc -L/lib/../lib -L/usr/lib/../lib -lgcc_s -lgcc -lcygwin -ladvapi32 -lshel l32 -luser32 -lkernel32 -lgcc_s -lgcc /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1 /cyg64/./gcc/crtend.o -Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++- symbols.ver -o .libs/cygstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --o ut-implib -Xlinker .libs/libstdc++.dll.a .libs/compatibility.o: In function `std::basic_istream<char, std::char_traits >::ignore(long)': /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/x86_64-unknown-cygwin/libstdc++ -v3/src/../../../../libstdc++-v3/src/c++98/compatibility.cc:67: undefined refere nce to `std::basic_istream<char, std::char_traits >::sentry::sentry(std::b asic_istream<char, std::char_traits >&, bool)'
[Bug fortran/68365] New: gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 Bug ID: 68365 Summary: gfortran test case showing performance loss with vectorization Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Target Milestone: --- Created attachment 36716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36716=edit gzip tar file of Fortran and C source files Just recently, it has become necessary to add the omp simd safelen(1) directive in subroutine s111 in order to prevent a vectorization which reduces performance on all known IA targets other than Intel Xeon Phi. The same situation occurs in gcc/g++, and (for several years) icc/icpc (but not ifort). make -j 3 -f Makefile.cygwin lcd_ffast I haven't tested the latest gfortran build on linux, but I do have a Makefile for that, in case it's useful. In the Makefile, CLOCK_RATE is set to enable accurate translation from rdtsc ticks to seconds. The timing quotations for VL=100 and VL=1000 will show the reduced performance of s111 when vectorized by removing safelen(1) . For gcc and g++, functions s128() and s4113() also need vectorization disable for full performance, but gfortran doesn't exhibit that problem. For this filing, you can ignore everything but subroutine s111.
[Bug target/68365] gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 --- Comment #2 from tprince at computer dot org --- Created attachment 36722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36722=edit fortran source gfortran -c lcdmod.f90 should take care of the missing .mod
[Bug c/67967] New: ICE in i386_pe_seh_unwind_emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67967 Bug ID: 67967 Summary: ICE in i386_pe_seh_unwind_emit Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Target Milestone: --- Created attachment 36510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36510=edit C source 1st of many build failures on trunk: $ /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/gcc/xgcc -B/cygdrive/c/users /tim/tim/tim/src/gnu/gcc1/cyg64/gcc/ -I../../../winsup/w32api/include -I../.. /../winsup/include -I../../../winsup/cygwin/include -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-proto types -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-l ibgcc -fno-stack-protector -I. -I../../gcc -I../../../libgcc -I../../../gcc - I../../../include -I../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT - DHAVE_CC_TLS -DUSE_EMUTLS -o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep -DL_powitf2 -c ../../../libgcc/libgcc2.c ../../../libgcc/libgcc2.c: In function ‘__powitf2’: ../../../libgcc/libgcc2.c:1851:1: internal compiler error: in i386_pe_seh_unwind _emit, at config/i386/winnt.c:1137 } ^ unable to obtain pre-processed source $ /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/gcc/xgcc Target: x86_64-unknown-cygwin Configured with: ../configure --prefix=/usr/local/gcc6.0 --enable-languages='c c ++ fortran' --enable-libgomp --enable-threads=posix --with-dwarf2 --without-libi conv-prefix --without-libintl-prefix --with-system-zlib --disable-werror --witho ut-cloog --without-isl --disable-__cxa_atexit --disable-bootstrap Thread model: posix gcc version 6.0.0 20151014 (experimental) (GCC)
[Bug c/67967] ICE in i386_pe_seh_unwind_emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67967 --- Comment #1 from tprince at computer dot org --- Created attachment 36511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36511=edit include file
[Bug c/67967] ICE in i386_pe_seh_unwind_emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67967 --- Comment #2 from tprince at computer dot org --- Created attachment 36512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36512=edit C source According to ChangeLog, ktietz is the one who modified this since it was last working (verified on 26 Sept. 2015). There are hundreds of failures pointing to the same source line, between build and test suite.
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 --- Comment #6 from tprince at computer dot org --- Created attachment 36295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36295=edit pre-processed C source pre-processed, without function calls
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 --- Comment #5 from tprince at computer dot org --- Created attachment 36294 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36294=edit shortened c code C source with external function calls removed
[Bug tree-optimization/66740] [6 Regression] omp simd reduction miscompiles at -O3 with AVX (recent regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66740 --- Comment #4 from tprince at computer dot org --- It optimizes with implicit simd reduction and gives correct result with option -ffast-math in place of -fopenmp.
[Bug c/66740] omp simd reduction miscompiles at -O3 with AVX (recent regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66740 --- Comment #2 from tprince at computer dot org --- $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc6.0/libexec/gcc/x86_64-unknown-cygwin/6.0.0/lt o-wrapper.exe Target: x86_64-unknown-cygwin Configured with: ../configure --prefix=/usr/local/gcc6.0 --enable-languages='c c ++ fortran' --enable-libgomp --enable-threads=posix --with-dwarf2 --without-libi conv-prefix --without-libintl-prefix --with-system-zlib --disable-werror --witho ut-cloog --without-isl Thread model: posix gcc version 6.0.0 20150630 (experimental) (GCC)
[Bug c/66740] omp simd reduction miscompiles at -O3 with AVX (recent regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66740 --- Comment #3 from tprince at computer dot org --- $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc6.0/libexec/gcc/x86_64-unknown-cygwin/6.0.0/lt o-wrapper.exe Target: x86_64-unknown-cygwin Configured with: ../configure --prefix=/usr/local/gcc6.0 --enable-languages='c c ++ fortran' --enable-libgomp --enable-threads=posix --with-dwarf2 --without-libi conv-prefix --without-libintl-prefix --with-system-zlib --disable-werror --witho ut-cloog --without-isl Thread model: posix gcc version 6.0.0 20150630 (experimental) (GCC)
[Bug c/66740] omp simd reduction miscompiles at -O3 with AVX (recent regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66740 --- Comment #1 from tprince at computer dot org --- Created attachment 35898 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35898action=edit C source
[Bug c/66740] New: omp simd reduction miscompiles at -O3 with AVX (recent regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66740 Bug ID: 66740 Summary: omp simd reduction miscompiles at -O3 with AVX (recent regression) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Target Milestone: --- Created attachment 35897 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35897action=edit f2c include file This regression is new in the last 2 weeks. gcc -O3 -march=sandybridge -std=c99 -D__assume_aligned= -fopenmp -c s115.c is miscompiled (bad numerical results when run under test harness). It is OK at -O2 or with -march=westmere, or with the omp directive disabled. It doesn't vectorize without the omp directive. It fails the same with -march=haswell. Similar versions using inner_product or Fortran dot_product are vectorizing correctly without omp simd.
[Bug c++/65835] bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835 tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from tprince at computer dot org --- The problem appears to have been cleared in trunk by 2015-05-19
[Bug c++/65835] New: bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835
Bug ID: 65835
Summary: bootstrap failure: multiple invalid conversions from
‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tprince at computer dot org
Created attachment 35380
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35380action=edit
winnt.c from trunk
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-
W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-
attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wn
o-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc
-I../../gc
c/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I../../gc
c/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/
../libbacktrace -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I./.
./intl -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber
-I../../gcc/..
/libdecnumber/bid -I../libdecnumber -I../../gcc/../libbacktrace \
../../gcc/config/i386/winnt-stubs.c
../../gcc/config/i386/winnt.c: In function ‘const char*
i386_find_on_wrapper_lis
t(const char*)’:
../../gcc/config/i386/winnt.c:804:32: error: invalid conversion from ‘const
char
*’ to ‘hash_tablewrapped_symbol_hasher::value_type {aka char*}’
[-fpermissive]
return wrappers-find (target);
^
In file included from ../../gcc/hard-reg-set.h:23:0,
from ../../gcc/regs.h:24,
from ../../gcc/config/i386/winnt.c:26:
../../gcc/hash-table.h:623:15: note: initializing argument 1 of
‘hash_tableDe
scriptor, Allocator::value_type hash_tableDescriptor, Allocator::find(const
value_type) [with Descriptor = wrapped_symbol_hasher; Allocator = xcallocator;
hash_tableDescriptor, Allocator::value_type = char*]’
value_type find (const value_type value)
...
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-
W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-
attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wn
o-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc
-I../../gc
c/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include
-I../../gc
c/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/
../libbacktrace -o hooks.o -MT hooks.o -MMD -MP -MF ./.deps/hooks.TPo
../../gc
c/hooks.c
../../gcc/config/i386/winnt.c: In function ‘void i386_pe_file_end()’:
../../gcc/config/i386/winnt.c:832:50: error: invalid conversion from ‘const
char
*’ to ‘char*’ [-fpermissive]
char *realsym = i386_find_on_wrapper_list (p-name);
^
../../gcc/config/i386/winnt.c:770:1: note: initializing argument 1 of ‘char*
i
386_find_on_wrapper_list(char*)’
i386_find_on_wrapper_list (char *target)
^
[Bug c++/65835] bootstrap failure: multiple invalid conversions from ‘const char*’ to ‘char*’ [-fpermissive] in winnt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65835 --- Comment #1 from tprince at computer dot org --- Building by casting const char* to char *
[Bug c/65653] cilkplus reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65653 --- Comment #1 from tprince at computer dot org --- Created attachment 35205 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35205action=edit pre-processed C source
[Bug c/65653] cilkplus reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65653 --- Comment #2 from tprince at computer dot org --- runs well with Intel C++ Windows/linux
[Bug c/65653] New: cilkplus reducer ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65653 Bug ID: 65653 Summary: cilkplus reducer ICE Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Created attachment 35204 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35204action=edit cilkplus C source gcc -c -fcilkplus s319.i gcc version 5.0.0 20150326 s319.c:82:41: internal compiler error: in gimplify_expr, at gimplify.c:8629 (a[1:i__2]=c__[1:i__2]+d__[1:i__2]) +
[Bug c/63336] New: cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 Bug ID: 63336 Summary: cilkplus array notation ICE in find_rank Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Created attachment 33534 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33534action=edit pre-processed C source with cilkplus array notation $ gcc -std=c99 -c -fcilkplus -v s422.i Using built-in specs. COLLECT_GCC=gcc Target: x86_64-unknown-cygwin Configured with: ../configure --prefix=/usr/local/gcc5.0 --enable-languages='c c ++ fortran' --enable-libgomp --enable-threads=posix --disable-__cxa_atexit --wit h-dwarf2 --without-libiconv-prefix --without-libintl-prefix --with-system-zlib - -disable-werror --without-cloog --without-isl Thread model: posix gcc version 5.0.0 20140922 (experimental) (GCC) COLLECT_GCC_OPTIONS='-std=c99' '-c' '-fcilkplus' '-v' '-mtune=generic' '-march=x 86-64' '-pthread' /usr/local/gcc5.0/libexec/gcc/x86_64-unknown-cygwin/5.0.0/cc1.exe -fpreprocesse d s422.i -quiet -dumpbase s422.i -mtune=generic -march=x86-64 -auxbase s422 -std =c99 -version -fcilkplus -o /tmp/ccCsOctk.s GNU C (GCC) version 5.0.0 20140922 (experimental) (x86_64-unknown-cygwin) compiled by GNU C version 5.0.0 20140922 (experimental), GMP version 6.0 .0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 5.0.0 20140922 (experimental) (x86_64-unknown-cygwin) compiled by GNU C version 5.0.0 20140922 (experimental), GMP version 6.0 .0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 418ff77cc465e61e11d739c56dbe80c7 s422.c: In function ‘s422_’: s422.c:86:5: internal compiler error: in find_rank, at c-family/array-notation-c ommon.c:231 } ^ Please submit a full bug report,
[Bug c/61612] New: trunk revision 211984 winnt.c ‘hash_table_c’ does not name a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61612 Bug ID: 61612 Summary: trunk revision 211984 winnt.c ‘hash_table_c’ does not name a type Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org stage1 build fails (host==target==x86_64-pc-cygwin) ../../gcc/config/i386/winnt.c: In function ‘const char* i386_find_on_wrapper_lis t(const char*)’: ../../gcc/config/i386/winnt.c:787:22: error: ‘hash_table_c’ does not name a type wrappers = new hash_table_cwrapped_symbol_hasher (8); ^ ../../gcc/config/i386/winnt.c:787:56: error: expected primary-expression before ‘’ token wrappers = new hash_table_cwrapped_symbol_hasher (8); ^ ../../gcc/config/i386/t-cygming:26: recipe for target 'winnt.o' failed
[Bug c/61212] New: gcc build failure on dos file system due to warnings treated as errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61212 Bug ID: 61212 Summary: gcc build failure on dos file system due to warnings treated as errors Product: gcc Version: fortran-dev Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org gcc trunk and fortran-dev build failure ../../libcpp/files.c:393:56: error: suggest parentheses around ‘’ within ‘||’ [-Werror=parentheses] if (CPP_OPTION (pfile, canonical_system_headers) file-dir-sysp ^ cc1plus: all warnings being treated as errors Adding the parens as suggested has been working: if ((CPP_OPTION (pfile, canonical_system_headers) file-dir-sysp) #ifdef HAVE_DOS_BASED_FILE_SYSTEM || !file-dir-sysp #endif ) Apparently, this is exposed only on dos based file system.
[Bug c/60117] New: simd reduction clause suppresses simd auto-vectorization when -fopenmp is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60117 Bug ID: 60117 Summary: simd reduction clause suppresses simd auto-vectorization when -fopenmp is set Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Created attachment 32082 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32082action=edit source code reproducer gcc version 4.9.0 20140203 gcc -O2 -ftree-vectorize -std=c99 -march=core-avx2 -fopt-info -S -fopenmp s314.c This uses vmaxss instruction in the main loop body, in spite of the fairly positive vectorization report. -O3 makes no significant difference, so -O2 is used in practice for stability elsewhere in gcc source code. If the omp simd is disabled by removing -fopenmp, excellent code is produced using vmaxps. Performance test shows 10x speedup with max-unroll-times=2.
[Bug c/60117] simd reduction clause suppresses simd auto-vectorization when -fopenmp is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60117 --- Comment #1 from tprince at computer dot org --- Created attachment 32083 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32083action=edit f2c style include file
[Bug c/60117] simd reduction clause suppresses simd auto-vectorization when -fopenmp is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60117 --- Comment #2 from tprince at computer dot org --- Jakub Jelinek requested this PR filing
[Bug c/58942] New: cilkplus internal compiler error: tree check __sec_reduce_max_ind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58942 Bug ID: 58942 Summary: cilkplus internal compiler error: tree check __sec_reduce_max_ind Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Created attachment 31123 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31123action=edit pre-processed source gcc -O2 -ftree-vectorize -fopenmp -std=c99 -funroll-loops --param max-unroll-times=4 -c -fcilkplus s315.i s315.c: In function ‘s315_’: s315.c:89:5: internal compiler error: tree check: accessed operand 2 of indirect_ref with 1 operands in fix_builtin_array_notation_fn, at c/c-array-notation.c:477 } ^ 0xbe4721 tree_operand_check_failed(int, tree_node const*, char const*, int, char const*) ../../gcc/tree.c:9507 0x5e09bf tree_operand_check ../../gcc/tree.h:3127 0x5e09bf fix_builtin_array_notation_fn ../../gcc/c/c-array-notation.c:477 0x5e28dd build_array_notation_expr(unsigned int, tree_node*, tree_node*, tree_code, unsigned int, tree_node*, tree_node*) ../../gcc/c/c-array-notation.c:640 0x5e5478 expand_array_notation_exprs(tree_node*) ../../gcc/c/c-array-notation.c:1275 0x5e5108 expand_array_notation_exprs(tree_node*) ../../gcc/c/c-array-notation.c:1263 0x5d91eb c_parser_compound_statement ../../gcc/c/c-parser.c:4174 0x5d7267 c_parser_statement_after_labels ../../gcc/c/c-parser.c:4570 0x5db593 c_parser_c99_block_statement ../../gcc/c/c-parser.c:4757 0x5dbb36 c_parser_for_statement ../../gcc/c/c-parser.c:5219 0x5d76b3 c_parser_statement_after_labels ../../gcc/c/c-parser.c:4588 0x5d8926 c_parser_compound_statement_nostart ../../gcc/c/c-parser.c:4338 0x5d917e c_parser_compound_statement ../../gcc/c/c-parser.c:4170 0x5da0fa c_parser_declaration_or_fndef ../../gcc/c/c-parser.c:1810 0x5dd995 c_parser_external_declaration ../../gcc/c/c-parser.c:1380 0x5de439 c_parser_translation_unit ../../gcc/c/c-parser.c:1267 0x5de439 c_parse_file() ../../gcc/c/c-parser.c:13297 0x62e753 c_common_parse_file() ../../gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug c/58942] cilkplus internal compiler error: tree check __sec_reduce_max_ind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58942 --- Comment #1 from tprince at computer dot org --- gcc -O2 -ftree-vectorize -fopenmp -std=c99 -funroll-loops --param max-unroll-times=4 -c -fcilkplus -v s315.i Using built-in specs. COLLECT_GCC=gcc Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc-4.9 --enable-languages='c c++ fortran' Thread model: posix gcc version 4.9.0 20131031 (experimental) (GCC) COLLECT_GCC_OPTIONS='-O2' '-ftree-vectorize' '-fopenmp' '-std=c99' '-funroll-loops' '--param' 'max-unroll-times=4' '-c' '-fcilkplus' '-v' '-mtune=generic' '-march=x86-64' '-pthread' /usr/local/gcc-4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1 -fpreprocessed s315.i -quiet -dumpbase s315.i -mtune=generic -march=x86-64 -auxbase s315 -O2 -std=c99 -version -ftree-vectorize -fopenmp -funroll-loops -fcilkplus --param max-unroll-times=4 -o /tmp/ccwvvwef.s GNU C (GCC) version 4.9.0 20131031 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.0 20131031 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.9.0 20131031 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.0 20131031 (experimental), GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 0002240542c88ef466dc653c18157e56
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from tprince at computer dot org --- Fixes my test case.
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #1 from tprince at computer dot org --- Created attachment 30798 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30798action=edit pre-processed source
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #2 from tprince at computer dot org --- Created attachment 30799 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30799action=edit C source
[Bug libgomp/58392] New: internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 Bug ID: 58392 Summary: internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org CC: jakub at gcc dot gnu.org Created attachment 30797 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30797action=edit log file describe above gomp_4.0-branch up to date gcc -O2 -ftree-vectorize -fopenmp -std=c99 -funroll-loops --param max-unroll-times=4 -ffast-math -march=native -c -x c -v s3110.i build.log 2 1 default backtrace in attached build.log. Unable to find compatible glib-debuginfo rpm for current installation.
[Bug libgomp/58392] internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58392 --- Comment #3 from tprince at computer dot org --- Created attachment 30801 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30801action=edit include file needed for compilation from C source
[Bug c++/51669] New: ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669 Bug #: 51669 Summary: ICE verify-gimple with openmp Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tpri...@computer.org Created attachment 26173 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26173 pre-processed C++ source [tim@tim-knf1 gf]$ g++ -O1 -fopenmp -Drestrict=__restrict__ -v s451.i Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7-20111217/configure --enable-languages='c c++ fortran' --disable-multilib Thread model: posix gcc version 4.7.0 20111217 (experimental) (GCC) COLLECT_GCC_OPTIONS='-O1' '-fopenmp' '-D' 'restrict=__restrict__' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-pthread' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/cc1plus -fpreprocessed s451.i -quiet -dumpbase s451.i -mtune=generic -march=x86-64 -auxbase s451 -O1 -version -fopenmp -o /tmp/ccVyBz2P.s GNU C++ (GCC) version 4.7.0 20111217 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20111217 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 warning: MPC header version 0.9 differs from library version 0.8. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.7.0 20111217 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20111217 (experimental), GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9 warning: MPC header version 0.9 differs from library version 0.8. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 19c710f37412ac153ea3c68c9b7fb9cd s451.cpp: In function ‘int s451_(integer*, integer*, integer*, real*, real*, real*, real*, real*, real*, real*, real*, real*, real*)’: s451.cpp:46:1: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4244
[Bug libstdc++/36211] New: __iconv_adaptor chooses char** where const char** is required
libstdc++ testsuite cases which require libiconv fail on account of trying the wrong choice in __iconv_adaptor: /cygdrive/c/gnu/gcc-4.4-20080509/xp/i686-pc-cygwin/libstdc++-v3/include/ext/code cvt_specializations.h:302: undefined reference to `_libiconv'^M #ifndef LIBICONV_PLUG #define iconv libiconv #endif extern size_t iconv (iconv_t cd, const char* * inbuf, size_t *inbytesleft, char* * outbuf, size_t *outbytesleft); -- Summary: __iconv_adaptor chooses char** where const char** is required Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #1 from tprince at computer dot org 2008-05-11 15:57 --- 2 unicode.cc tests fail. Several other tests with -liconv pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #3 from tprince at computer dot org 2008-05-11 17:26 --- I see that the failing case is looking for a libiconv in the library to match the char ** prototype, and failing to find one, while the one in the actual library is set up for the const char ** version. The comment in codecvt_specializations.h indicates this should be taken care of by __iconv_adaptor, yet the link failure shows this is not working. I don't understand the usage well enough to know what to conclude, why some cases (do they also exercise __iconv_adaptor ?) work, while the unicode.cc cases fail to link at that point. This problem has been brought up by others in mail lists, but as far as I know no one wrote up a PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #5 from tprince at computer dot org 2008-05-11 18:04 --- Only the gcc-testresults reports where others report the same thing are clearly relevant: http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg01444.html http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01528.html In other cases, the poster did not provide sufficient information to establish conclusively it was the same problem. It is generally not reported in testresults whether libstdc++ tests were run with libiconv installed. If libiconv is not installed, none of these tests are attempted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug libstdc++/36211] __iconv_adaptor chooses char** where const char** is required
--- Comment #8 from tprince at computer dot org 2008-05-12 01:58 --- Yes, -liconv precedes the source file, where it must follow: Executing on host: /cygdrive/c/gnu/gcc-4.4-20080509/xp/./gcc/g++ -shared-libgcc -B/cygdrive/c/gnu/gcc-4.4-20080509/xp/./gcc -nostdinc++ -L/cygdrive/c/gnu/gcc-4. 4-20080509/xp/i686-pc-cygwin/libstdc++-v3/src -L/cygdrive/c/gnu/gcc-4.4-20080509 /xp/i686-pc-cygwin/libstdc++-v3/src/.libs -B/usr/local/gcc44/i686-pc-cygwin/bin/ -B/usr/local/gcc44/i686-pc-cygwin/lib/ -isystem /usr/local/gcc44/i686-pc-cygwin /include -isystem /usr/local/gcc44/i686-pc-cygwin/sys-include -g -O2 -D_GLIBCXX_ ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -D LOCALEDIR=. -nostdinc++ -I/cygdrive/c/gnu/gcc-4.4-20080509/xp/i686-pc-cygwin/l ibstdc++-v3/include/i686-pc-cygwin -I/cygdrive/c/gnu/gcc-4.4-20080509/xp/i686-pc -cygwin/libstdc++-v3/include -I/cygdrive/c/gnu/gcc-4.4-20080509/libstdc++-v3/lib supc++ -I/cygdrive/c/gnu/gcc-4.4-20080509/libstdc++-v3/include/backward -I/cygdr ive/c/gnu/gcc-4.4-20080509/libstdc++-v3/testsuite/util -Wl,--gc-sections -liconv /cygdrive/c/gnu/gcc-4.4-20080509/libstdc++-v3/testsuite/22_locale/locale/cons/u nicode.cc-include bits/stdc++.h ./libtestc++.a -o ./unicode.exe (time -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36211
[Bug tree-optimization/31041] [4.3 Regression] verify_stmts failed: invalid operand to binary operator with -O2 -ftree-vectorize
--- Comment #8 from tprince at computer dot org 2008-03-03 16:20 --- pr31341 has a patch attached to allow the test case to run on targets where there is checking for conflicts with stdint.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug testsuite/20360] 20021014-1.c fails on account of unsupported build option
--- Comment #6 from tprince at computer dot org 2008-03-03 16:26 --- gcc-3.4.4 testsuite still shows the failure; none of the proposed fixes were applied. -- tprince at computer dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20360
[Bug testsuite/31341] testsuite pr31041.c fails conflicting with stdint.h
--- Comment #4 from tprince at computer dot org 2008-02-28 17:05 --- With Victor's patch on SVN: trunk revision 132553 version 4.4.0 20080222: PASS: gcc.dg/vect/pr31041.c (test for excess errors) -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31341
[Bug testsuite/31341] testsuite pr31041.c fails conflicting with stdint.h
--- Comment #5 from tprince at computer dot org 2008-02-28 21:07 ---
(In reply to comment #3)
I have no installed cygwin, could you check if this patch fixes the failure?
Index: gcc/testsuite/gcc.dg/vect/pr31041.c
===
--- gcc/testsuite/gcc.dg/vect/pr31041.c (revision 131411)
+++ gcc/testsuite/gcc.dg/vect/pr31041.c (working copy)
@@ -4,16 +4,15 @@
#include stdarg.h
#include tree-vect.h
-typedef int int32_t;
struct UNewTrie
{
- int32_t index[(0x11 1)];
+ int index[(0x11 1)];
};
typedef struct UNewTrie UNewTrie;
utrie_open_3_4 ()
{
UNewTrie *trie;
- int32_t i, j;
+ int i, j;
{
i = 0;
do
Yes, it passes now, as I reported on bugzilla. Will you submit the patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31341
[Bug testsuite/32932] New: ssp-2.c fails when previous gcc-4.3 installation is visible
/usr/local/gcc43/lib/gcc/i686-pc-cygwin/4.3.0/../../../libssp.a(ssp.o):ssp.c:(.t ext+0x190): multiple definition of `___stack_chk_fail'^M /cygdrive/c/Temp/ccrBTHWE.o:ssp-2.c:(.text+0x0): first defined here^M collect2: ld returned 1 exit status^M function declaration in testsuite conflicts with function present in libssp.a of previous installation of gcc 4.3 -- Summary: ssp-2.c fails when previous gcc-4.3 installation is visible Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32932
[Bug debug/28834] [4.0/4.1/4.2/4.3 Regression] -g crashes sometimes when using may_alias and structs (ICE in splice_child_die)
--- Comment #27 from tprince at computer dot org 2007-07-29 18:00 --- same failure for gcc-4.3 mainline on i686-pc-cygwin -- tprince at computer dot org changed: What|Removed |Added CC||tprince at computer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
[Bug testsuite/32932] ssp-2.c fails when previous gcc-4.3 installation is visible
--- Comment #1 from tprince at computer dot org 2007-07-29 20:15 --- This test is reported failing also by anonymous testers of powerpc-apple-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32932
[Bug middle-end/23845] missed strength reduction costs performance
--- Comment #5 from tprince at computer dot org 2007-07-29 20:57 --- No longer relevant, due to changes in gfortran. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug testsuite/31340] testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise
--- Comment #2 from tprince at computer dot org 2007-07-29 20:54 --- The suggested function name change is in mainline, and this resolves the bug. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31340
[Bug testsuite/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #8 from tprince at computer dot org 2007-07-29 21:02 --- The patch discussed here was incorporated in mainline, and the failure was last reported 20070420. -- tprince at computer dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug fortran/32380] misaligned stores don't get vectorized
--- Comment #4 from tprince at computer dot org 2007-07-15 18:43 --- The arrays in this example all have compatible alignment. This is one of the advantages many compilers see in the use of the old-fashioned block COMMON. In the usual case lft==1 all arrays in COMMON are aligned, with the size declarations given here. So it is undesirable to split the loop to handle alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380
[Bug fortran/32373] New: not vectorized: can't determine dependence (equivalence)
gfortran -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -c k90.f90 Shows missed vectorization at source lines 125,332,380, 638 These problems appear to be associated with the EQUIVALENCE (source line 92), which names one or more of the arrays involved. -- Summary: not vectorized: can't determine dependence (equivalence) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373
[Bug fortran/32373] not vectorized: can't determine dependence (equivalence)
--- Comment #1 from tprince at computer dot org 2007-06-17 14:11 --- Created an attachment (id=13718) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13718action=view) source code which reproduces problem with equivalence This source code is derived from the public version posted at http://www.llnl.gov/asci_benchmarks/asci/limited/lfk/README.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373
[Bug fortran/32375] New: not vectorized: can't determine dependence (array sections)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s414a.f The source and destination sections of aa(:,:) do not overlap, unless there is a subscript over-run. Even that case could be taken care of by loop reversal. This is a simplification of a case from: http://www.netlib.org/benchmark/vectors -- Summary: not vectorized: can't determine dependence (array sections) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
[Bug fortran/32375] not vectorized: can't determine dependence (array sections)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:04 --- Created an attachment (id=13720) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13720action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32375
[Bug fortran/32376] New: can't determine dependence (array with variable initial index)
The original case from http://www.netlib.org/benchmark/vectors is split into 2 array assignments which should be easily vectorizable. The first assignment, which starts at the base of the arrays, is vectorized. The second assignment, which begins where the first left off, is not vectorized. -- Summary: can't determine dependence (array with variable initial index) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32376
[Bug fortran/32376] can't determine dependence (array with variable initial index)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:15 --- Created an attachment (id=13721) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13721action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32376
[Bug fortran/32377] New: can't determine dependence (source/destination overlap)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s243.f The first array assignment is vectorized. The second, which involves overlap between source and destination, should be no problem to vectorize as long as the loop is not reversed. Significant advantage should be gained by fusion. Simplified from http://www.netlib.org/benchmark/vectors -- Summary: can't determine dependence (source/destination overlap) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/32377] can't determine dependence (source/destination overlap)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:26 --- Created an attachment (id=13722) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13722action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/32378] New: can't determine dependence (distinct sections of an array)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s174.f The two sections of the array are clearly distinct, so it should be vectorized. -- Summary: can't determine dependence (distinct sections of an array) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug fortran/32378] can't determine dependence (distinct sections of an array)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:36 --- Created an attachment (id=13723) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13723action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug fortran/32379] New: can't determine dependence (loop reversal required)
gfortran -O2 -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v s112.f The case could be vectorized by taking the array elements in reverse order (as specified in the source). ifort vectorizes by creating a temporary array (when the reversal is removed from the source), losing performance. -- Summary: can't determine dependence (loop reversal required) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32379
[Bug fortran/32379] can't determine dependence (loop reversal required)
--- Comment #1 from tprince at computer dot org 2007-06-17 15:45 --- Created an attachment (id=13724) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13724action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32379
[Bug fortran/32380] New: reports unaligned store and can't determine dependence
gfortran -O2 -fcray-pointer -ftree-vectorize -ftree-vectorizer-verbose=2 -c -v unal.f There are several reports of unsupported unaligned store or can't determine dependence between .. The loops which report unaligned store vectorize OK when taken in isolation. The reports of can't determine dependence appear to refer to the use of multiple sections of the same array. These sections cannot overlap unless there is a subscript range violation. Even if there were such a violation, it could be taken care of by changing the order. -- Summary: reports unaligned store and can't determine dependence Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380
[Bug fortran/32380] reports unaligned store and can't determine dependence
--- Comment #1 from tprince at computer dot org 2007-06-17 16:29 --- Created an attachment (id=13725) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13725action=view) source code test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32380
[Bug fortran/32377] can't determine dependence (source/destination overlap)
--- Comment #2 from tprince at computer dot org 2007-06-18 01:36 --- Performance change due to complete vectorization is not significant on Core 2 Duo. My apologies for submitting at normal priority. -- tprince at computer dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug fortran/32378] can't determine dependence (distinct sections of an array)
--- Comment #2 from tprince at computer dot org 2007-06-18 01:39 --- Performance change for full vectorization is not significant on Core 2 Duo; suggest reduced ;priority, apologies for submitting at normal severity -- tprince at computer dot org changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32378
[Bug testsuite/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #5 from tprince at computer dot org 2007-04-27 17:02 --- According to my test of Dorit's updated patch, the following are now PASS: vect-iv-9.c vect-iv-4.c pr30771.c The patch changed FAIL to XFAIL for the following vect-reduc-dot-u16b.c vect-widen-mult-u16.c vect-reduc-dot-u16a.c The following still reports a FAIL: PASS: gcc.dg/vect/no-section-anchors-vect-69.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/tim/src/gcc-4.3-20070413/ia64/gcc::/home/tim/src/gcc-4.3-20070413/ia64/gcc:/opt/intel/fc/9.1.045/lib:/opt/intel/mpi/3.0/lib PASS: gcc.dg/vect/no-section-anchors-vect-69.c execution test PASS: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times vectorized 4 loops 1 PASS: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times Alignment of access forced using peeling 3 Is it possible the xfail pattern does not match ia64-unknown-linux-gnu ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug testsuite/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #6 from tprince at computer dot org 2007-04-27 23:56 --- I retyped the xfail instruction after applying the patch, and now gcc.dg/vect/no-section-anchors-vect-69.c shows XFAIL as intended, with the patch Dorit posted yesterday. My patch must have been corrupted with invisible characters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug testsuite/31341] testsuite pr31041.c fails conflicting with stdint.h
--- Comment #2 from tprince at computer dot org 2007-04-28 06:42 --- Whatever the reason, cygwin has more headers active than just those specified in the file. I would have thought that stdint.h typedefs should be acquired from stdint.h rather than being specified slightly differently in the source, for no apparent reason, but it's not my call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31341
[Bug fortran/31561] FAIL: gfortran.dg/vect/vect-4.f90
--- Comment #8 from tprince at computer dot org 2007-04-19 14:35 --- 4.2 branch appears to have the identical problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
[Bug testsuite/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #3 from tprince at computer dot org 2007-04-18 02:21 --- The patch which Dorit proposed does change the FAIL in the testsuite case vect-reduc-dot-u16a.c to XFAIL, according to my test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug c/31589] New: gcc.dg/vect failures due to missing target specifiers
Dorit Nuzman supplied a patch to correct failures reported when running testsuite. These failures have been reported in all results posted to gcc-testsuite. The patch adds target specifiers, correcting the associated FAIL reports on my system, for the cases pr30771.c vect-iv-4.c vect-iv-9.c vect-reduc-dot-s16b.c vect-reduc-dot-u16b.c vect-reduc-pattern-1a.c vect-reduc-pattern-1c.c vect-reduc-pattern-2a.c vect-widen-mult-u16.c wrapv-vect-reduc-pattern-2c.c 2 more are under investigation: no-section-anchors-vect-69.c vect-reduc-dot-u16a.c -- Summary: gcc.dg/vect failures due to missing target specifiers Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: ia64-unknown-linux-gnu GCC host triplet: ia64-unknown-linux-gnu GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug c/31589] gcc.dg/vect failures due to missing target specifiers
--- Comment #1 from tprince at computer dot org 2007-04-16 14:18 --- Created an attachment (id=13371) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13371action=view) adds target qualifiers to files in gcc.dg/vect/ patch supplied to me by Dorit Nuzman. It changes ia64 reports from FAIL to UNSUPPORTED. I tested it successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
[Bug fortran/31561] FAIL: gfortran.dg/vect/vect-4.f90
--- Comment #5 from tprince at computer dot org 2007-04-14 17:59 ---
I tested successfully the patch proposed by dorit, which changes the report of
these 2 cases to XFAIL for vect_no_align target:
Index: vect-4.f90
===
--- vect-4.f90 (revision 123409)
+++ vect-4.f90 (working copy)
@@ -10,7 +10,7 @@
END
! { dg-final { scan-tree-dump-times vectorized 1 loops 1 vect } }
-! { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 1 vect } }
-! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1
vect } }
+! { dg-final { scan-tree-dump-times Alignment of access forced using
peeling 1 vect { xfail vect_no_align } } }
+! { dg-final { scan-tree-dump-times Vectorizing an unaligned access 1
vect { xfail vect_no_align } } }
! { dg-final { scan-tree-dump-times accesses have the same alignment. 1
vect } }
! { dg-final { cleanup-tree-dump vect } }
--
tprince at computer dot org changed:
What|Removed |Added
CC||tprince at computer dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31561
[Bug c/31340] New: testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise
signal.h is in scope when gcc.dg/setjmp-3.c and setjmp-4.c are compiled. The attempt to redefine raise() causes the tests to fail. Either this should be an XFAIL, or the test should be changed so as to remove the conflict with pre-existing definition. The definition in the testsuite conflicts with Open Group specification http://www.opengroup.org/onlinepubs/95399/functions/raise.html -- Summary: testsuite setjmp-3 and setjmp-4 fail attempting to redefine raise Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31340
[Bug c/31341] New: testsuite pr31041.c fails conflicting with stdint.h
gcc.dg/vect/pr31041 attempts to redefine int32_t while stdint.h is in scope, so test reports FAIL. Is this the intent of the test? -- Summary: testsuite pr31041.c fails conflicting with stdint.h Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31341
[Bug c/31342] New: testsuite i386/pic-1.c FAILed for warning -fPIC ignored
This case issues the warning -fPIC ignored and is FAILed on account of it. -- Summary: testsuite i386/pic-1.c FAILed for warning -fPIC ignored Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31342
[Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- Comment #2 from tprince at computer dot org 2007-03-24 01:22 --- Note that the newly built bootstrap compiler fails the configure tests which have a trailing -V on the command line. Nearly all the various configure scripts provoke this failure. The one cited here happens to be the first. -- tprince at computer dot org changed: What|Removed |Added CC||tprince at computer dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- Comment #3 from tprince at computer dot org 2007-03-24 03:06 --- The failure can be worked around by commenting out the section of stdio.h in the cygwin distribution which sets __SCLE (conversion of \r\n to \n, according to comments). The code thus commented out apparently requires some cygwin extensions in the library which have disappeared since 20070224 (quoted by submitter as last working build). I concur, having built successfully the 20070223. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug middle-end/23845] missed strength reduction costs performance
--- Additional Comments From tprince at computer dot org 2005-09-13 23:15 --- Created an attachment (id=9726) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9726action=view) include files from libgfortran, required in build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug c/23845] New: missed strength reduction costs performance
Dictation of strength reduction in source is required for adequate performance
on this target. The same source optimization is counter-productive for ia32.
This is a portion of the diff file between 2 versions of
libgfortran/generated/matmul_r8.c.
for (n = 0; n count; n++)
{
! abase_n = abase + n * aystride;
sum += abase_n[x] * bbase_y[n];
sum1 += abase_n[x+1] * bbase_y[n];
--- 199,208
{
rtype_name sum = 0, sum1 = 0;
+ index_type nay = 0;
for (n = 0; n count; n++)
{
! /* FIXME: gcc ought to strength reduce from n * aystride */
! abase_n = abase + nay;
! nay += aystride;
sum += abase_n[x] * bbase_y[n];
sum1 += abase_n[x+1] * bbase_y[n];
--
Summary: missed strength reduction costs performance
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tprince at computer dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-unknown-linux-gnu
GCC host triplet: ia64-unknown-linux-gnu
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug middle-end/23845] missed strength reduction costs performance
--- Additional Comments From tprince at computer dot org 2005-09-13 00:13 --- Created an attachment (id=9714) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9714action=view) alternate version of libgfortran/generated/matmul_r8.c The C file in the attachment performs well on ia32. The patch in the .diff file must be applied to work around the missing strength reduction, in order to perform adequately on ia64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23845
[Bug c/23808] New: ICE in convert-move, building libgfortran with tree-vectorize
GNU C version 4.1.0 20050909 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.1.0 20050909 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: f9d7f64473108ed4ae233ca41e01773c GNU assembler version 2.14.90.0.4 (x86_64-redhat-linux) using BFD version 2.14.9 0.0.4 20030523 ../../../libgfortran/generated/maxloc0_4_i4.c: In function 'mmaxloc0_4_i4': ../../../libgfortran/generated/maxloc0_4_i4.c:231: internal compiler error: in c onvert_move, at expr.c:390 -- Summary: ICE in convert-move, building libgfortran with tree- vectorize Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23808
[Bug c/21311] New: ice on valid code tree-vectorize (max of float array)
gcc -O -march=pentium4 -ftree-vectorize -c -std=c99 -v loopsv.c Using built-in specs. Target: i686-pc-cygwin Configured with: ../configure --enable-languages=c c++ f95 objc treelang --enable-threads=posix --enable-sjlj-exceptions --disable-libmudflap --disable-shared Thread model: posix gcc version 4.1.0 20050424 (experimental) GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 s314.c:2: warning: return type defaults to 'int' s314.c: In function 's314_': s314.c:2: error: Definition in block 4 follows the use for SSA_NAME: i___23 in statement: x_2 = i__2_15 = i___23 ? x_22 : x_25; s314.c:2: internal compiler error: verify_ssa failed. -- Summary: ice on valid code tree-vectorize (max of float array) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21311
[Bug c/21311] ice on valid code tree-vectorize (max of float array)
--- Additional Comments From tprince at computer dot org 2005-05-01 00:34 --- Created an attachment (id=8779) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8779action=view) pre-processed C code exhibiting ice in -ftree-vectorize This is the netlib Levine-Callahan-Dongarra vector function s314, C translation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21311
[Bug tree-optimization/20926] New: ICE: tree check, in recent builds, multiple functions in file
gfortran -c -v -O -march=pentium4 llnt.f90 GNU F95 version 4.1.0 20050403 (experimental) (i686-pc-cygwin) compiled by GNU C version 4.1.0 20050403 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 llnt.f90: In function 'supply': llnt.f90:4931: internal compiler error: tree check: expected ssa_name, have var_ decl in verify_ssa, at tree-ssa.c:684 -- Summary: ICE: tree check, in recent builds, multiple functions in file Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tprince at computer dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
[Bug tree-optimization/20926] ICE: tree check, in recent builds
--- Additional Comments From tprince at computer dot org 2005-04-10 13:30 --- Created an attachment (id=8575) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8575action=view) A Livermore Fortran Kernel driver, reproduces ICE as described -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
[Bug tree-optimization/20926] ICE: tree check, in recent builds
--- Additional Comments From tprince at computer dot org 2005-04-10 13:34 --- Created an attachment (id=8576) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8576action=view) A Livermore Fortran Kernel driver, reproduces ICE as described The functions can be compiled one by one without exhibiting this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20926
