[Bug other/60158] powerpc: usage of the .data.rel.ro.local section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 --- Comment #2 from Alan Modra --- Fixed on master with git commit 8e2a42caa / svn rev 223209. Fixed for gcc-4.9 with git commit 110222ca0 / svn rev 223714. Fixed for gcc-4.8 with git commit 071358356 / svn rev 223713. Oddly, not backported to gcc-5? Regarding the testcase, you won't get .fixup entries unless a section other than .got/.got2 is holding addresses, which makes it a rather poor test.
[Bug fortran/68268] New: configure: error: GNU Fortran is not working;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68268 Bug ID: 68268 Summary: configure: error: GNU Fortran is not working; Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: isearcher at 126 dot com Target Milestone: --- Created attachment 36672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36672&action=edit config.log I want to upgrade gfortran on a linux sever with gcc version 4.1.2 20080704 (Red Hat 4.1.2-48).I use the configure command like this: ./configure --prefix=/wk5/WJ/gcc -enable-threads=posix -disable-checking -disable-multilib -enable-languages=c,fortran --with-gmp=/wk5/WJ/gmp-4.3.2 --with-mpfr=/wk5/WJ/mpfr-2.4.2 --with-mpc=/wk5/WJ/mpc-0.8.1 When i make gcc,i found this error: libtool.m4: error: problem compiling FC test program ... checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /wk5/WJ/tmp/gcc-4.8.0/x86_64-unknown-linux-gnu/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make[1]: Leaving directory `/wk5/WJ/tmp/gcc-4.8.0' make: *** [all] Error 2 the config.log is also attached. Is there anybody knows what's the problem? thanks.
[Bug fortran/68268] configure: error: GNU Fortran is not working;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68268 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Dominique d'Humieres --- Read https://gcc.gnu.org/install/configure.html > First, we highly recommend that GCC be built into a separate directory > from the sources which does not reside within the source tree. > This is how we generally build GCC; building where srcdir == objdir > should still work, but doesn't get extensive testing; building where > objdir is a subdirectory of srcdir is unsupported.
[Bug c++/68265] Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 Andreas Schwab changed: What|Removed |Added CC||yaghmour.shafik at gmail dot com --- Comment #1 from Andreas Schwab --- *** Bug 68262 has been marked as a duplicate of this bug. ***
[Bug c++/68262] Ill-formed function pointer declaration acts as multi-line comment until ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68262 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 68265 ***
[Bug c++/68267] over-aligning with alignas() doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68267 --- Comment #1 from Andreas Schwab --- Which target? This is probably BIGGEST_ALIGNMENT.
[Bug target/68256] [6 regression] switching constant pools to rodata sections causes go bootstrap failure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68256 --- Comment #2 from Ramana Radhakrishnan --- Author: ramana Date: Tue Nov 10 08:35:21 2015 New Revision: 230085 URL: https://gcc.gnu.org/viewcvs?rev=230085&root=gcc&view=rev Log: Workaround PR68256 on AArch64 > This is causing a bootstrap comparison failure in gcc/go/gogo.o. I've had a look at this and the trigger is the aarch64_use_constant_blocks_p change which appears to be causing a bootstrap comparison failure because of differences to offsets when built with debug and without debug. I don't think the problem is specifically in the backend but this needs some careful investigation. For now, in the interest of go bootstraps continuing on trunk - I'm proposing a patch that partially rolls back the change in aarch64_use_constant_blocks_p and am still looking into the issue but it will take me some more time to get to the bottom of the issue. Bootstrapped on aarch64-none-linux-gnu including (c,c++ and go) - testing finished ok. 2015-11-10 Ramana Radhakrishnan PR bootstrap/68256 * config/aarch64/aarch64.c (aarch64_use_constant_blocks_p): Return false. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68263 --- Comment #2 from H.J. Lu --- The maximum stack alignment is 4 byte for IA MCU. That is why reload generates misaligned load/store.
[Bug c++/68267] over-aligning with alignas() doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68267 --- Comment #2 from Markus Trippelsdorf --- (In reply to Andreas Schwab from comment #1) > Which target? This is probably BIGGEST_ALIGNMENT. x86_64-pc-linux-gnu. You're right it works fine with e.g -march=skylake. Since handling of anything bigger than BIGGEST_ALIGNMENT is implementation defined, this is not bug per se.
[Bug c++/68267] over-aligning with alignas() doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68267 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Markus Trippelsdorf --- Closing.
[Bug rtl-optimization/68269] New: [5/6 regression] FAIL: gcc.dg/pr68129_1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68269 Bug ID: 68269 Summary: [5/6 regression] FAIL: gcc.dg/pr68129_1.c (internal compiler error) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Target Milestone: --- Target: ia64-*-* Both -O and -fno-split-wide-types are required to trigger the ICE. $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/pr68129_1.c -O -fno-split-wide-types -S -o pr68129_1.s ../gcc/testsuite/gcc.dg/pr68129_1.c: In function ‘foo’: ../gcc/testsuite/gcc.dg/pr68129_1.c:10:1: internal compiler error: in simplify_const_binary_operation, at simplify-rtx.c:3950 } ^ 0x40c3a8bf simplify_const_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) ../../gcc/simplify-rtx.c:3950 0x40c3a54f simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*) ../../gcc/simplify-rtx.c:1990 0x40c4376f simplify_gen_binary(rtx_code, machine_mode, rtx_def*, rtx_def*) ../../gcc/simplify-rtx.c:194 0x414fc92f expand_field_assignment ../../gcc/combine.c:7234 0x414ffc3f can_combine_p ../../gcc/combine.c:1910 0x4152e55f try_combine ../../gcc/combine.c:2961 0x4153c06f combine_instructions ../../gcc/combine.c:1267 0x4153c06f rest_of_handle_combine ../../gcc/combine.c:14278 0x4153c06f execute ../../gcc/combine.c:14321
[Bug tree-optimization/68264] tree-call-cdce wrongly uses ordered comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68264 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-10 CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Will try to fix this as a prerequisite to the internal function changes.
[Bug rtl-optimization/68269] [5/6 regression] FAIL: gcc.dg/pr68129_1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68269 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.3
[Bug rtl-optimization/68236] [6 Regression] selective scheduling with --param=sched-autopref-queue-depth=10 ICEs a lot @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68236 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Nov 10 09:22:58 2015 New Revision: 230088 URL: https://gcc.gnu.org/viewcvs?rev=230088&root=gcc&view=rev Log: [haifa-sched] PR rtl-optimization/68236: Exit early from autoprefetcher lookahead if not in haifa sched PR rtl-optimization/68236 * haifa-sched.c (autopref_multipass_dfa_lookahead_guard): Return 0 if insn_queue doesn't exist. (haifa_sched_finish): Reset insn_queue to NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c
[Bug rtl-optimization/68236] [6 Regression] selective scheduling with --param=sched-autopref-queue-depth=10 ICEs a lot @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68236 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug target/68261] GCC needs to use optimized version of memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68261 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- There is nothing to do for GCC here, GCC traditionally relies on the system runtime to provide memcpy (if not inlined).
[Bug c++/68258] core 879 Missing built-in comparison operators for pointer types not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68258 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Ever confirmed|0 |1 Known to fail||6.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68263 --- Comment #3 from Uroš Bizjak --- (In reply to H.J. Lu from comment #2) > The maximum stack alignment is 4 byte for IA MCU. That is why > reload generates misaligned load/store. It looks to me that BIGGEST_ALIGNMENT is defined in a wrong way. If you want to use SSE with TARGET_IAMCU, then it needs to be defined to 128.
[Bug middle-end/68251] [6 Regression] sorry, unimplemented: reverse storage order for BLKmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68251 --- Comment #9 from Eric Botcazou --- > thanks, the issue is fixed indeed. Attached is the reduced testcase, about > 1000 lines remain, but at least it can be compiled in ~2s. Thanks, I have installed it in the testsuite.
[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118 --- Comment #11 from Richard Biener --- Author: rguenth Date: Tue Nov 10 09:43:54 2015 New Revision: 230091 URL: https://gcc.gnu.org/viewcvs?rev=230091&root=gcc&view=rev Log: 2015-11-10 Richard Biener PR tree-optimization/56118 * tree-vect-slp.c (vect_bb_vectorization_profitable_p): Make equal cost favor vectorized version. * gcc.target/i386/pr56118.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr56118.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/56118] Piecewise vector / complex initialization from constants not combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56118 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed.
[Bug other/68270] New: Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270
Bug ID: 68270
Summary: Common pattern for variable sized data clashes with
MPX bound checks
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jussi.judin at ericsson dot com
Target Milestone: ---
A very common pattern due to pedantic C89, C90, and C++ compatibility is to
declare an array of size 1 when having a structure with a variable sized member
at the end. GCC's memory protection extensions, however, work in a way that
only zero/variable sized members are treated in such way that their bounds are
not explicitly checked
(https://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler#line-142).
This makes it impossible to use existing code with MPX checks without changes
that go through large amount of header files that use this pattern of arrays
size 1.
To demonstrate this issue, here are 3 different ways to indicate structures
with a variable sized array at the end of the structure:
typedef struct struktura1 {
long len;
char data[];
} struktura1;
typedef struct struktura2 {
long len;
char data[0];
} struktura2;
typedef struct struktura3 {
long len;
char data[1] __attribute__((bnd_variable_size));
} struktura3;
If we compile them with different standards and warning levels, we'll get these
kind of results:
$ gcc-5.2.0 --std=c89 -pedantic tst.c
tst.c:3:10: warning: ISO C90 does not support flexible array members
[-Wpedantic]
char data[];
^
tst.c:8:10: warning: ISO C forbids zero-size array ‘data’ [-Wpedantic]
char data[0];
$ gcc-5.2.0 -xc++ --std=c++14 -pedantic tst.c
tst.c:3:15: warning: ISO C++ forbids zero-size array ‘data’ [-Wpedantic]
char data[];
^
tst.c:8:16: warning: ISO C++ forbids zero-size array ‘data’ [-Wpedantic]
char data[0];
$ gcc-4.8 --std=c11 -pedantic tst.c
tst.c:8:10: warning: ISO C forbids zero-size array ‘data’ [-Wpedantic]
char data[0];
^
tst.c:13:5: warning: ‘bnd_variable_size’ attribute directive ignored
[-Wattributes]
char data[1] __attribute__((bnd_variable_size));
^
Not to mention that a lot of code is compiled with other compilers than GCC
that don't know about "bnd_variable_size" attribute, so making the code shown
above to be compatible with different compilers and also having MPX checks in
place requires some macro magic depending on which compiler is in use and which
standard the compilation is done against.
GCC should ignore or have an option to ignore bound checks for arrays of size 1
at the end of the structure so that just trying out MPX support wouldn't need
large scale changes to existing code bases.
[Bug tree-optimization/68238] Vector cost model overestimates prologue cost for SLPed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68238 --- Comment #2 from James Greenhalgh --- Author: jgreenhalgh Date: Tue Nov 10 10:08:03 2015 New Revision: 230092 URL: https://gcc.gnu.org/viewcvs?rev=230092&root=gcc&view=rev Log: [Patch GCC 5/Vect] Partial backport of r228751 (pr68238) gcc/ Partial backport from trunk r228751. PR tree-optimization/68238 2015-10-13 Richard Biener * tree-vect-loop.c (vect_estimate_min_profitable_iters): Use LOOP_VINFO_COMP_ALIAS_DDRS to estimate alias versioning cost. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/tree-vect-loop.c
[Bug tree-optimization/68248] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in uniform_vector_p, at tree.c:10807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68248 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/68129] [5/6 Regression] ICE: in simplify_const_binary_operation, at simplify-rtx.c:3961 (TARGET_SUPPORTS_WIDE_INT == 0) with -fno-split-wide-types @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68129 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Nov 10 10:12:11 2015 New Revision: 230093 URL: https://gcc.gnu.org/viewcvs?rev=230093&root=gcc&view=rev Log: [AArch64] PR target/68129: Define TARGET_SUPPORTS_WIDE_INT PR target/68129 * config/aarch64/aarch64.h (TARGET_SUPPORTS_WIDE_INT): Define to 1. * config/aarch64/aarch64.c (aarch64_print_operand, CONST_DOUBLE): Delete VOIDmode case. Assert that mode is not VOIDmode. * config/aarch64/predicates.md (const0_operand): Remove const_double match. * gcc.target/aarch64/pr68129_1.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68129_1.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/aarch64.c branches/gcc-5-branch/gcc/config/aarch64/aarch64.h branches/gcc-5-branch/gcc/config/aarch64/predicates.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/68129] [5/6 Regression] ICE: in simplify_const_binary_operation, at simplify-rtx.c:3961 (TARGET_SUPPORTS_WIDE_INT == 0) with -fno-split-wide-types @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68129 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from ktkachov at gcc dot gnu.org --- Fixed on trunk and GCC 5
[Bug tree-optimization/68240] [6 Regression] compilation hangs on valid code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68240 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Nov 10 10:14:02 2015 New Revision: 230095 URL: https://gcc.gnu.org/viewcvs?rev=230095&root=gcc&view=rev Log: 2015-11-10 Richard Biener PR tree-optimization/68240 * tree-ssa-sccvn.c (cond_stmts_equal_p): Handle commutative compares properly. (visit_phi): For PHIs with just a single executable edge take its value directly. (expressions_equal_p): Handle VN_TOP properly. * gcc.dg/torture/pr68240.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr68240.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/68240] [6 Regression] compilation hangs on valid code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68240 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68263 --- Comment #4 from Yulia Koval --- Why should TARGET_IAMCU support SSE?
[Bug bootstrap/68271] New: [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 Bug ID: 68271 Summary: [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: cesar at gcc dot gnu.org, iains at gcc dot gnu.org, jakub at gcc dot gnu.org, nathan at gcc dot gnu.org Target Milestone: --- Boostrap fails on x86_64-apple-darwin14 at r230084. The first failure is at stage 1 /../work/libstdc++-v3/libsupc++/array_type_info.cc libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/src/.libs -L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/ -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -isystem /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/include -isystem /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/sys-include -I/opt/gcc/work/libstdc++-v3/../libgcc -I/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/include/x86_64-apple-darwin14.5.0 -I/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/include -I/opt/gcc/work/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -frandom-seed=array_type_info.lo -g -O2 -c ../../../../work/libstdc++-v3/libsupc++/array_type_info.cc -D_GLIBCXX_SHARED : internal compiler error: in c_register_pragma_1, at c-family/c-pragma.c:1375 Applying the patch --- ../_clean/gcc/c-family/c-pragma.c 2015-11-10 01:54:43.0 +0100 +++ gcc/c-family/c-pragma.c 2015-11-10 10:00:06.0 +0100 @@ -1372,7 +1372,7 @@ c_register_pragma_1 (const char *space, /* The C++ front end allocates 6 bits in cp_token; the C front end allocates 7 bits in c_token. At present this is sufficient. */ - gcc_assert (id < 64); + gcc_assert (id < 128); } cpp_register_deferred_pragma (parse_in, space, name, id, allowed me to reach stage 3 for a new failure libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/i386/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/i386/libstdc++-v3/src/.libs -L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/i386/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/ -B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -isystem /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/include -isystem /opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/sys-include -m32 -DHAVE_CONFIG_H -I. -I../../../../work/libjava -I./include -I./gcj -I../../../../work/libjava -Iinclude -I../../../../work/libjava/include -I../../../../work/libjava/classpath/include -Iclasspath/include -I../../../../work/libjava/classpath/native/fdlibm -I../../../../work/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../../work/libjava/libltdl -I../../../../work/libjava/libltdl -I../../../../work/libjava/.././libjava/../libgcc -I../../../../work/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/opt/gcc/gcc6w\" -DTOOLEXECLIBDIR=\"/opt/gcc/gcc6w/lib/i386\" -DJAVA_HOME=\"/opt/gcc/gcc6w\" -DBOOT_CLASS_PATH=\"/opt/gcc/gcc6w/share/java/libgcj-6.0.0.jar\" -DJAVA_EXT_DIRS=\"/opt/gcc/gcc6w/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/opt/gcc/gcc6w/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/opt/gcc/gcc6w/lib/i386/gcj-6.0.0-16\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"/opt/gcc/gcc6w/share/java/ecj.jar\" -DLIBGCJ_DEFAULT_DATABASE=\"/opt/gcc/gcc6w/lib/i386/gcj-6.0.0-16/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-6.0.0-16/classmap.db\" -g -O2 -m32 -MT jni-libjvm.lo -MD -MP -MF .deps/jni-libjvm.Tpo -c ../../../../work/libjava/jni-libjvm.cc -fno-common -DPIC -o .libs/jni-libjvm.o In file included from ../../../../work/libjava/java/lang/Object.h:16:0, from ../../../../work/libjava/gcj/cni.h:16, from ../../../../work/libjava/jni-libjvm.cc:11: ../../../../work/libjava/gcj/javaprims.h:17:9: internal compiler error: in cp_parser_pragma, at cp/parser.c:36474 #pragma GCC java_exceptions ^ I have tried the following patch --- ../_clean/gcc/cp/parser.c 2015-11-10 09:21:41.0 +0100 +++ gcc/cp/parser.c 2015-11-10 11:41:41.0 +0100 @@ -36471,7 +36471,7 @@ cp_parser_pragma (cp_parser *parser, enu } default: - gcc_assert (id >= PRAGMA_FIRST_EXTERNAL); + /* gcc_asser
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from Richard Biener --- How do you end up registering so many pragmas? I can't see anything in darwin specific code.
[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68270 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Component|other |middle-end Summary|Common pattern for variable |[MPX] Common pattern for |sized data clashes with MPX |variable sized data clashes |bound checks|with MPX bound checks --- Comment #1 from Richard Biener --- MPX should just behave like the rest of GCC treating _all_ trailing arrays as possibly flexible.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 Dominique d'Humieres changed: What|Removed |Added Target||x86_64-apple-darwin14 Host||x86_64-apple-darwin14 Build||x86_64-apple-darwin14 --- Comment #2 from Dominique d'Humieres --- > How do you end up registering so many pragmas? I can't see anything in > darwin specific code. No idea! Last successful bootstrap was r230059.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #3 from Jakub Jelinek --- DARWIN_REGISTER_TARGET_PRAGMAS registers 5. If I count well on Linux and yesterday's trunk, for -fopenmp -fopenacc -fcilkplus I see 10 OpenACC, 25 OpenMP, 2 Cilk+ and 22 other deferred pragmas being registered, if you add 5 to that it is 64. The comment in c-family is clearly outdated, the C parser uses 8 bits for pragma_kind. But, looking at parser.h, I see /* The kind of token. */ ENUM_BITFIELD (cpp_ttype) type : 8; /* If this token is a keyword, this value indicates which keyword. Otherwise, this value is RID_MAX. */ ENUM_BITFIELD (rid) keyword : 8; /* Token flags. */ unsigned char flags; /* Identifier for the pragma. */ ENUM_BITFIELD (pragma_kind) pragma_kind : 6; /* True if this token is from a context where it is implicitly extern "C" */ BOOL_BITFIELD implicit_extern_c : 1; /* True if an error has already been reported for this token, such as a CPP_NAME token that is not a keyword (i.e., for which KEYWORD is RID_MAX) iff this name was looked up and found to be ambiguous. */ BOOL_BITFIELD error_reported : 1; /* True for a token that has been purged. If a token is purged, it is no longer a valid token and it should be considered deleted. */ BOOL_BITFIELD purged_p : 1; which if I count well is already 33 bits anyway, followed by 32-bit integer and pointer, therefore on 64-bit hosts there are 63 bits of padding and on 32-bit hosts 31 bits of padding.
[Bug target/57845] ICE with -freg-struct-return on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845 --- Comment #15 from Sergey Organov --- Eric, thanks a lot for taking care of the issue!
[Bug c++/68266] pointers to arrays of excessive size not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68266 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Seems that my patch for PR68107 fixes this as well.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- CCing Jason on the C++ token structure layout. Actually, the OpenMP/OpenACC/Cilk+ pragmas and 2 others are always assigned fixed numbers, and very recently one OpenACC pragma has been added, so we now have PRAGMA_FIRST_EXTERNAL 41, plus 20 generic externals, plus the 5 Darwin ones on Darwin.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #5 from Richard Biener --- Also look at vms-c.c which registers 14.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #3) > DARWIN_REGISTER_TARGET_PRAGMAS registers 5. > If I count well on Linux and yesterday's trunk, for -fopenmp -fopenacc > -fcilkplus I see 10 OpenACC, 25 OpenMP, 2 Cilk+ and 22 other deferred > pragmas being registered, if you add 5 to that it is 64. > The comment in c-family is clearly outdated, the C parser uses 8 bits for > pragma_kind. > But, looking at parser.h, I see > /* The kind of token. */ > ENUM_BITFIELD (cpp_ttype) type : 8; > /* If this token is a keyword, this value indicates which keyword. > Otherwise, this value is RID_MAX. */ > ENUM_BITFIELD (rid) keyword : 8; > /* Token flags. */ > unsigned char flags; > /* Identifier for the pragma. */ > ENUM_BITFIELD (pragma_kind) pragma_kind : 6; > /* True if this token is from a context where it is implicitly extern "C" > */ > BOOL_BITFIELD implicit_extern_c : 1; > /* True if an error has already been reported for this token, such as a > CPP_NAME token that is not a keyword (i.e., for which KEYWORD is > RID_MAX) iff this name was looked up and found to be ambiguous. */ > BOOL_BITFIELD error_reported : 1; > /* True for a token that has been purged. If a token is purged, > it is no longer a valid token and it should be considered > deleted. */ > BOOL_BITFIELD purged_p : 1; > which if I count well is already 33 bits anyway, followed by 32-bit integer > and pointer, therefore on 64-bit hosts there are 63 bits of padding and on > 32-bit hosts 31 bits of padding. That should be fixed of course. Maybe some unioning can be done as well based on 'type' (keyword?)
[Bug c/68272] New: Unwanted out-of-line instances for C inline functions that are also GCC builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272
Bug ID: 68272
Summary: Unwanted out-of-line instances for C inline functions
that are also GCC builtins.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sorganov at gmail dot com
Target Milestone: ---
When compiling C code, GCC generates out-of-line copy of any inline function
that also happens to be a GCC builtin, in every compilation unit that gets
inline definition, resulting in link errors (see a test-case below).
This violates C standard, as according to the standard, an out-of-line copy of
inline function should only be put in those compilation unit(s) where the
function is declared 'extern' as well.
To reproduce (notice no 'extern' declaration ever):
$ cat inl.h
inline int abs(int i) { return (i >= 0) ? i : -i; }
$ cat a.c
#include "inl.h"
int main() { return 1; }
$ cat b.c
#include "inl.h"
$ gcc a.c b.c
/tmp/ccyZFKSx.o: In function `abs':
b.c:(.text+0x0): multiple definition of `abs'
/tmp/ccijz638.o:a.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/4.9/lto-wrapper
Target: i586-linux-gnu
Configured with: [...]
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)
$
[Bug other/58133] GCC should emit arm assembly following the unified syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58133 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #6 from Ramana Radhakrishnan --- Fixed in ARM state by https://gcc.gnu.org/ml/gcc-cvs/2015-11/msg00242.html The compiler now emits assembler completely in unified syntax, inline assembler follows divided syntax for legacy reasons but can be moved up.
[Bug libstdc++/68156] --disable-hosted-libstdcxx doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68156 --- Comment #3 from Jonathan Wakely --- That's not what I said.
[Bug c++/68170] [6 Regression] Declaring friend template class template in C++1z produces error: specialization of ‘template class A’ must appear at namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68170 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Known to work||5.2.0 Summary|Declaring friend template |[6 Regression] Declaring |class template in C++1z |friend template class |produces error: |template in C++1z produces |specialization of |error: specialization of |‘template class A’ |‘template class A’ |must appear at namespace|must appear at namespace Ever confirmed|0 |1
[Bug target/68228] __builtin_ia32_pbroadcastd256 generates wrong insn at >= -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68228 --- Comment #4 from Micha³ Miros³aw --- Created attachment 36673 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36673&action=edit gcc 4.8 assembler output for -O1 gcc-4.8 also generates correct VPBROADCASTD, though with VMOVD before it.
[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68263 --- Comment #5 from H.J. Lu --- Created attachment 36674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36674&action=edit A patch
[Bug target/68263] Vector "*mov_internal" fails to handle misaligned load/store from reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68263 --- Comment #6 from H.J. Lu --- (In reply to Yulia Koval from comment #4) > Why should TARGET_IAMCU support SSE? It is about using SSE instructions with IAMCU psABI.
[Bug c++/68202] Missed diagnostic: rvalue reference allowed in exception-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68202 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Ever confirmed|0 |1
[Bug libstdc++/68200] g++ 5.2 optimizes out pointer assignment in libstdc++ mt_allocator freelist destructor, causing crash at global-dtor time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68200 --- Comment #3 from Jonathan Wakely --- I would like to deprecate mt_allocator, I don't recommend using it.
[Bug c++/68186] Using public base member function privately prevents derived classes using base member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68186 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Fails since at least 4.3.6
[Bug fortran/45715] [ABI cleanup] Move runtime parsing of I/O control list to front end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45715 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-10 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Any progress after four years and a half?
[Bug target/68261] GCC needs to use optimized version of memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68261 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- (In reply to Geir Johansen from comment #0) > The memcpy routine for GCC needs to be faster. The following test case > shows that the Intel compiler implementation of memcpy is over twice as fast > as GCC. I realize that memcpy is a part of GLIBC, but the GCC compiler > should take advantage of the targetting information being provided and the > context of the memcpy in order to provide more optimal code: The right mailing list to discuss this is probably libc-alpha and the right person to speak with is probably Ondřej Bílka: https://sourceware.org/ml/libc-alpha/2013-08/msg00161.html https://sourceware.org/ml/libc-alpha/2015-05/msg00600.html https://gcc.gnu.org/ml/gcc/2015-06/msg00057.html https://gcc.gnu.org/ml/gcc/2015-06/msg00059.html I think GCC still needs a person with the time and patience to serve as the bridge between Ondřej (and GNU libc) and GCC on this issue, since it is obvious that more collaboration is needed. If you are willing to be that person, it would help to familiarize yourself with the latest discussion in libc-alpha and g...@gcc.gnu.org.
[Bug libstdc++/68210] nothrow operator fails to call default new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Ever confirmed|0 |1
[Bug c++/68209] C++11 code compiled without -std=c++11 but doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68209 --- Comment #5 from Jonathan Wakely --- (In reply to Marc Glisse from comment #4) > Yes it is QoI, but we could still do better. Yes, I agree that if we accept it with only a warning then it should behave correctly.
[Bug c++/68208] g++ doesn't warn against reference self-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68208 --- Comment #1 from Jonathan Wakely --- I'm pretty sure this is a dup of a very old bug.
[Bug c++/68208] g++ doesn't warn against reference self-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68208 --- Comment #2 from Jonathan Wakely --- I thought I remembered dealing with this case as part of my patch for PR2972 but it doesn't look like it. PR19808 is also relevant here.
[Bug target/68223] [6 regression] arm_[su]min_cmp pattern fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68223 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Ramana Radhakrishnan --- Fixed by ...https://gcc.gnu.org/ml/gcc-cvs/2015-11/msg00262.html
[Bug libstdc++/68222] _Safe_iterator provides operators the wrapped iterator can't actually support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68222 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Yes, it would be nice if the wrapper operators were SFINAE-friendly. Wild idea off the top of my head: rather than SFINAE-ing away every member we could partially-specialize _Safe_iterator based on the iterator category.
[Bug go/68255] cgo-generated constructor not being called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255 --- Comment #1 from Dominik Vogt --- Created attachment 36675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36675&action=edit Experimental fix. The attached patch fixes the problem in the "go" tool by forcing the --whole-archive linker option if a package uses C code (Cgo). I've no idea whether the performance hit is acceptable. A different way to fix that would be to make Cgo place the init() function that initialise a global variable in the same .c file as the variable itself(?)
[Bug tree-optimization/68145] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68145 --- Comment #5 from Julian Taylor --- thanks, the full application now compiles successfully
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Ever confirmed|0 |1 --- Comment #7 from Dominique d'Humieres --- This is indeed caused by revision r230072.
[Bug sanitizer/68065] Size calculations for VLAs can overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68065 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 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, ||mpolacek at gcc dot gnu.org Component|c |sanitizer Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #16 from Marek Polacek --- Recategorizing as a ubsan RFE.
[Bug other/60158] powerpc: usage of the .data.rel.ro.local section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 --- Comment #3 from joakim.tjernlund at transmode dot se --- (In reply to Alan Modra from comment #2) > Fixed on master with git commit 8e2a42caa / svn rev 223209. > Fixed for gcc-4.9 with git commit 110222ca0 / svn rev 223714. > Fixed for gcc-4.8 with git commit 071358356 / svn rev 223713. > > Oddly, not backported to gcc-5? > > Regarding the testcase, you won't get .fixup entries unless a section other > than .got/.got2 is holding addresses, which makes it a rather poor test. Not sure I understand, you mean that the existing test is failing and so is my test? How would you suggest I amend the test case to really get a .fixup? The strange thing is that u-boot still fails with gcc 4.9.3 but disabling -fno-ira-hoist-pressure makes it work again. Maybe the fix is non functional in gcc 4.9.3?
[Bug tree-optimization/68238] Vector cost model overestimates prologue cost for SLPed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68238
--- Comment #3 from James Greenhalgh ---
Author: jgreenhalgh
Date: Tue Nov 10 14:40:43 2015
New Revision: 230110
URL: https://gcc.gnu.org/viewcvs?rev=230110&root=gcc&view=rev
Log:
[Patch GCC 4.9/Vect] Partial backport of r228751 (pr68238)
Partial backport from trunk r228751.
PR tree-optimization/68238
2015-10-13 Richard Biener
* tree-vect-loop.c (vect_estimate_min_profitable_iters): Use
LOOP_VINFO_COMP_ALIAS_DDRS to estimate alias versioning cost.
Modified:
branches/gcc-4_9-branch/ (props changed)
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/tree-vect-loop.c
Propchange: branches/gcc-4_9-branch/
('svn:mergeinfo' modified)
[Bug tree-optimization/68238] Vector cost model overestimates prologue cost for SLPed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68238 James Greenhalgh changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from James Greenhalgh --- Fixed on the relevant branches. Thanks for your help.
[Bug ipa/68273] New: Wrong code on mips/mipsel with -fno-ipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273
Bug ID: 68273
Summary: Wrong code on mips/mipsel with -fno-ipa-sra
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: aurelien at aurel32 dot net
Target Milestone: ---
Host: mipsel-linux-gnu
Target: mipsel-linux-gnu
Build: mipsel-linux-gnu
Created attachment 36676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36676&action=edit
preprocessed source
gsoap version 2.8.22 does not compile correctly on mips and mipsel with GCC
5.2.1 or trunk, while it compiles correctly on GCC 4.9. The resulting binary
segfaults.
A bit of analysis shows this is due to wrong code optimization at -O2 level,
and more specifically with the -fipa-sra option, which calls functions with
arguments in the wrong register.
I have not been able to get a simple testcase yet, but it is possible to
reproduce the issue with the attached preprocessed code. The problem occurs in
this function:
case 34:
# 436 "soapcpp2_yacc.y"
{ if ((yyvsp[-1].rec).sto & Stypedef)
{ sprintf(errbuf, "invalid typedef qualifier for '%s'",
(yyvsp[0].sym)->name);
semwarn(errbuf);
}
printf("%p\n", (yyvsp[0].sym));
p = enter(sp->table, (yyvsp[0].sym));
p->info.typ = (yyvsp[-1].rec).typ;
p->info.sto = (yyvsp[-1].rec).sto;
p->info.hasval = False;
p->info.offset = sp->offset;
if (sp->grow)
sp->offset += p->info.typ->width;
else if (p->info.typ->width > sp->offset)
sp->offset = p->info.typ->width;
sp->entry = p;
}
# 2290 "soapcpp2_yacc.c"
break;
When compiled with -O2, GCC outputs the following corresponding code:
$L380:
lw $25,%call16(__printf_chk)($28)
lw $21,%got(sp)($28)
lui $5,%hi($LC37)
move$6,$7
addiu $5,$5,%lo($LC37)
sw $7,13452($sp)
.reloc 1f,R_MIPS_JALR,__printf_chk
1: jalr$25
li $4,1# 0x1
lw $28,88($sp)
lw $2,0($21)
lw $7,13452($sp)
lw $4,0($2)
lw $25,%call16(enter)($28)
nop
.reloc 1f,R_MIPS_JALR,enter
1: jalr$25
move$6,$7
Note how the second argument is loaded in $6 (ie a2) instead of $5 (ie a1) when
calling enter.
When compiled with -O2 -fno-ipa-sra the correct register is used:
-O2 -fno-ipa-sra
$L387:
lw $25,%call16(__printf_chk)($28)
lw $21,%got(sp)($28)
lui $5,%hi($LC37)
move$6,$7
sw $7,13500($sp)
addiu $5,$5,%lo($LC37)
.reloc 1f,R_MIPS_JALR,__printf_chk
1: jalr$25
li $4,1# 0x1
lw $28,136($sp)
lw $2,0($21)
lw $7,13500($sp)
lw $4,0($2)
lw $25,%call16(enter)($28)
nop
.reloc 1f,R_MIPS_JALR,enter
1: jalr$25
move$5,$7
However it is first loaded to $7 for no obvious reason, especially this is not
a saved register, so its value is lost after the call. I am note sure it is
something related, but loading the value through this intermediate register is
due to the use of -O2, this is not the case -O1:
$L370:
lw $2,0($16)
nop
sw $2,13476($sp)
move$6,$2
lui $5,%hi($LC37)
addiu $5,$5,%lo($LC37)
li $4,1# 0x1
lw $25,%call16(__printf_chk)($28)
nop
.reloc 1f,R_MIPS_JALR,__printf_chk
1: jalr$25
nop
lw $28,136($sp)
nop
lw $17,%got(sp)($28)
nop
lw $2,0($17)
lw $5,13476($sp)
lw $4,0($2)
lw $25,%call16(enter)($28)
nop
.reloc 1f,R_MIPS_JALR,enter
1: jalr$25
nop
[Bug c/68274] New: __builtin_unreachable pessimizes code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
Bug ID: 68274
Summary: __builtin_unreachable pessimizes code
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: matt at godbolt dot org
Target Milestone: ---
While experimenting with __builtin_unreachable I found that in some cases
adding it pessimizes the code. Consider the following code (also at
https://goo.gl/WmR8PX):
--
enum Side { Bid, Ask };
struct Foo { int a; int b; };
int test(Side side, const Foo &foo) {
if (side == Bid) return foo.a;
return foo.b;
}
int test_with_unreach(Side side, const Foo &foo) {
if (side == Bid) return foo.a;
if (side != Ask) __builtin_unreachable();
return foo.b;
}
--
In the non-unreachable case `test`, the code generates the cmove I'd expect:
--
test(Side, Foo const&):
mov eax, DWORD PTR [rsi+4]
testedi, edi
cmove eax, DWORD PTR [rsi]
ret
--
In the unreachable case, GCC resorts back to branching:
--
test_with_unreach(Side, Foo const&):
testedi, edi
je .L9
mov eax, DWORD PTR [rsi+4]
ret
.L9:
mov eax, DWORD PTR [rsi]
ret
--
It's not really clear to me how much of a pessimization this is; but it was
surprising that the unreachability had such an effect.
I was hoping to prove to the compiler that the only valid inputs were "Bid" and
"Ask" and as such it could actually generate something like:
--
mov eax, DWORD PTR[rsi+eax*4]
ret
--
[Bug rtl-optimization/68185] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68185
--- Comment #2 from Thomas Preud'homme ---
Here's a quick update. What I found so far is that after split2, we have:
(insn 148 61 304 16 (set (reg:CCNO 17 flags)
(compare:CCNO (reg:HI 44 r15 [orig:91 pretmp_9 ] [91])
(const_int 0 [0]))) pr68185.c:20 2 {*cmphi_ccno_1}
(nil))
(insn 304 148 308 16 (set (reg/v:QI 5 di [orig:98 g ] [98])
(mem/c:QI (plus:DI (reg/f:DI 7 sp)
(const_int 15 [0xf])) [3 %sfp+-1 S1 A8])) pr68185.c:20 89
{*movqi_internal}
(nil))
(insn 308 304 67 16 (set (reg:SI 6 bp [orig:90 g ] [90])
(if_then_else:SI (gt (reg:CCNO 17 flags)
(const_int 0 [0]))
(reg:SI 6 bp [orig:90 g ] [90])
(reg:SI 5 di [orig:98 g ] [98]))) pr68185.c:20 957 {*movsicc_noc}
(nil))
(insn 67 308 151 16 (set (reg:SI 1 dx [orig:99 _23 ] [99])
(sign_extend:SI (reg/v:QI 6 bp [orig:90 g ] [90]))) pr68185.c:21 149
{extendqisi2}
(nil))
Where the second instruction load the value of w on the stack into di, then the
third instruction set bp to that value if t (in reg:HI 44) is smaller or equal
to 0 and then this value is extended into dx.
But after ree has run, we have:
(insn 148 61 304 16 (set (reg:CCNO 17 flags)
(compare:CCNO (reg:HI 44 r15 [orig:91 pretmp_9 ] [91])
(const_int 0 [0]))) pr68185.c:20 2 {*cmphi_ccno_1}
(nil))
(insn 304 148 312 16 (set (reg:SI 1 dx)
(sign_extend:SI (mem/c:QI (plus:DI (reg/f:DI 7 sp)
(const_int 15 [0xf])) [3 %sfp+-1 S1 A8]))) pr68185.c:20 149
{extendqisi2}
(nil))
(insn 312 304 308 16 (set (reg:SI 6 bp)
(reg:SI 1 dx)) pr68185.c:20 -1
(nil))
(insn 308 312 151 16 (set (reg:SI 6 bp [orig:90 g ] [90])
(if_then_else:SI (gt (reg:CCNO 17 flags)
(const_int 0 [0]))
(reg:SI 6 bp [orig:90 g ] [90])
(reg:SI 5 di [orig:98 g ] [98]))) pr68185.c:20 957 {*movsicc_noc}
(nil))
So the extension happens first from the value of w on the stack (insn 304),
then that value is put into bp (insn 312) and then bp takes the value of di
(which equals 0 at this point, coming from z I believe) if t (in reg:HI 44) is
smaller or equal to 0.
So the condition seems to have been reversed. This in turn leads to q not being
set to 1 after and thus the abort. Next step will be to investigate why ree
think this is safe to do, maybe some meta information not represented here that
was not updated correctly by loop2_invariant.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #8 from cesar at gcc dot gnu.org --- I'm not sure it will make much of a difference, but Thomas is planning on adding two openacc clauses bind and nohost. Is there anything I can do to help here, or is this already being taken care of?
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #13 from David Edelsohn --- The recent additions to GCC cxa atexit support on AIX may fix this.
[Bug c++/68266] pointers to arrays of excessive size not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68266 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-10 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1
[Bug tree-optimization/68274] __builtin_unreachable pessimizes code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Component|c |tree-optimization Ever confirmed|0 |1 Known to fail||6.0 --- Comment #1 from Richard Biener --- Without the unreachable PHI-OPT will host the loads (via hoist_adjacent_loads) but not with it. Thus we end up with the if-convertible : _5 = foo_4(D)->a; _6 = foo_4(D)->b; if (side_2(D) == 0) goto ; else goto ; : : # _1 = PHI <_5(2), _6(3)> compared to : if (side_2(D) == 0) goto ; else goto ; : _5 = foo_4(D)->a; goto ; : _6 = foo_4(D)->b; : # _1 = PHI <_5(3), _6(4)> which is not if-convertible (by RTL if-conversion which doesn't perform this trick itself).
[Bug ipa/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||jamborm at gcc dot gnu.org Target Milestone|--- |5.3 Summary|Wrong code on mips/mipsel |[5/6 Regression] Wrong code |with -fipa-sra |on mips/mipsel with ||-fipa-sra
[Bug libstdc++/68190] [5/6 Regression] iterator mix up with set::find and heterogenous lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Tue Nov 10 15:12:24 2015 New Revision: 230113 URL: https://gcc.gnu.org/viewcvs?rev=230113&root=gcc&view=rev Log: Fix return type of heterogeneous find for sets PR libstdc++/68190 * include/bits/stl_multiset.h (multiset::find): Fix return types. * include/bits/stl_set.h (set::find): Likewise. * testsuite/23_containers/map/operations/2.cc: Test find return types. * testsuite/23_containers/multimap/operations/2.cc: Likewise. * testsuite/23_containers/multiset/operations/2.cc: Likewise. * testsuite/23_containers/set/operations/2.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_multiset.h trunk/libstdc++-v3/include/bits/stl_set.h trunk/libstdc++-v3/testsuite/23_containers/map/operations/2.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/operations/2.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/operations/2.cc trunk/libstdc++-v3/testsuite/23_containers/set/operations/2.cc
[Bug tree-optimization/68275] New: bb-slp-38 FAILs on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275 Bug ID: 68275 Summary: bb-slp-38 FAILs on armeb Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Target: armeb-none-linux-gnueabihf Created attachment 36677 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36677&action=edit slp1 log, big-endian The vect/bb-slp-38.c test recently introduced fails on armeb and passes on arm. GCC configured as: --target=armeb-none-linux-gnueabihf --with-float=hard --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon I attach the vectorizer logs in LE and BE modes.
[Bug tree-optimization/68275] bb-slp-38 FAILs on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275 --- Comment #2 from Christophe Lyon --- Created attachment 36679 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36679&action=edit slp2 log, big-endian
[Bug tree-optimization/68275] bb-slp-38 FAILs on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275 --- Comment #3 from Christophe Lyon --- Created attachment 36680 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36680&action=edit slp2 log, little-endian
[Bug libstdc++/68197] negative index to ios_base::iword lead to unpredictable result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68197 --- Comment #1 from Jonathan Wakely --- I would argue that your program has undefined behaviour, there is no array element at a negative index.
[Bug tree-optimization/68275] bb-slp-38 FAILs on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275 --- Comment #1 from Christophe Lyon --- Created attachment 36678 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36678&action=edit slp1 log, little-endian
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 Jason Merrill changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #9 from Jason Merrill --- The cp_token::pragma_kind field seems like a waste of bits; why can't we leave the pragma kind in token->u.value? RTH, do you remember why you added this field?
[Bug libstdc++/68276] New: ios_base::_M_grow_words should use new (std::nothrow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68276 Bug ID: 68276 Summary: ios_base::_M_grow_words should use new (std::nothrow) Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- To avoid aborting on allocation failure when the library is compiled with -fno-exceptions, _M_grow_words should use nothrow new and check for null, instead of catching std::bad_alloc.
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #14 from Hugo Koblmueller --- David, which version does/will include these recent additions? I recently encountered a crash on program exit in AIX 6.1, in a setup where I used a static C++ objects inside functions within a shared library (accessed via dlfcn interfaces & closed via dlclose), compiled with a gcc-4.6.3. Having the gcc configure flag "--enable-__cxa_atexit" in place and working (meaning cxa_atexit is present) shall fix this issue.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #10 from Richard Henderson --- I believe the tokens didn't stay around in C at the time. But I might be wrong... it was 9 years ago... If we can remove it, it does seem like a good idea.
[Bug bootstrap/68271] [6 Regression] Boostrap fails on x86_64-apple-darwin14 at r230084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271 --- Comment #11 from Jakub Jelinek --- (In reply to Richard Henderson from comment #10) > I believe the tokens didn't stay around in C at the time. > But I might be wrong... it was 9 years ago... > > If we can remove it, it does seem like a good idea. I believe they still don't stay around in C, but they do stay around in C++. So perhaps we could just add cp_parser_get_pragma_kind routine or similar that would for a token return us a pragma_kind and use it in the 5 or how many spots, plus adjust the c-family assert to be id < 256 and state that C FE reserves 8 bits for pragma_kind and C++ FE doesn't have an upper bound.
[Bug c++/54601] AIX uses atexit which causes unloading of shared modules to break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54601 --- Comment #15 from David Edelsohn --- GCC development trunk and it will be in GCC 5.3.
[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-10 Ever confirmed|0 |1 Known to fail||5.2.1 --- Comment #5 from Jonathan Wakely --- Fails with gcc-5-branch, but doesn't fail on trunk for me.
[Bug target/68277] New: [5] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277
Bug ID: 68277
Summary: [5] [SH]: error: insn does not satisfy its constraints
when compiling erlang
Product: gcc
Version: 5.2.1
URL: https://buildd.debian.org/status/fetch.php?pkg=erlang&;
arch=sh4&ver=1%3A18.1-dfsg-1&stamp=1447057369
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: kkojima at gcc dot gnu.org, olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
Created attachment 36681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36681&action=edit
Pre-processed source for beam/erl_alloc.c from erlang
Hi!
Compiling on Debian sh4 with gcc-5 fails with:
beam/erl_alloc.c: In function 'reply_alloc_info':
beam/erl_alloc.c:3223:1: error: insn does not satisfy its constraints:
}
^
(insn 4435 4434 857 66 (set (reg:SI 5 r5)
(plus:SI (reg:SI 1 r1)
(const_int 40 [0x28]))) ../include/internal/gcc/ethr_membar.h:196
65 {*addsi3}
(nil))
beam/erl_alloc.c:3223:1: internal compiler error: in extract_constrain_insn, at
recog.c:2246
Full build log in [1]. Attaching pre-processed source cc1AGEHe.out.
Let me know if you need any additional input.
Cheers,
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=erlang&arch=sh4&ver=1%3A18.1-dfsg-1&stamp=1447057369
[Bug fortran/65454] Extending both forms of relational operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65454 --- Comment #4 from Paul Martin --- For information : The Silverfrost FTN95 compiler , version 7.20 compiles with no errors the program submitted in Comment 0 (though I had to delete two '::' separators). It gives the same results as the ifort compiler. Recorded Cygwin session is below : bash 2 : uname -smo CYGWIN_NT-6.1-WOW i686 Cygwin bash 3 : cat oper1.f90 MODULE deriv_m IMPLICIT NONE TYPE deriv_t INTEGER :: i END TYPE deriv_t INTERFACE OPERATOR (<=) MODULE PROCEDURE deriv_LE_deriv END INTERFACE OPERATOR (<=) CONTAINS ELEMENTAL FUNCTION deriv_LE_deriv (a, b) RESULT (c) TYPE(deriv_t), INTENT(IN) :: a, b LOGICAL :: c c = a%i .LE. b%i END FUNCTION deriv_LE_deriv END MODULE deriv_m PROGRAM oper USE deriv_m, ONLY: deriv_t, OPERATOR(.LE.) IMPLICIT NONE TYPE(deriv_t) :: one = deriv_t(1), two = deriv_t(2) WRITE (*,'(A,L1)') '(one <= two) = ', one <= two WRITE (*,'(A,L1)') '(one .LE. two) = ', one .LE. two END PROGRAM oper bash 4 : ftn95 oper1.f90 /ISO /CHECK /RESTRICT_SYNTAX /LINK [FTN95/Win32 Ver. 7.20.0 Copyright (c) Silverfrost Ltd 1993-2015] PROCESSING MODULE [ FTN95/Win32 v7.20.0] NO ERRORS [ FTN95/Win32 v7.20.0] NO ERRORS [ FTN95/Win32 v7.20.0] NO ERRORS [ FTN95/Win32 v7.20.0] Creating executable: oper1.EXE bash 5 : ./oper1.EXE (one <= two) = T (one .LE. two) = T Greetings Paul
[Bug tree-optimization/68274] __builtin_unreachable pessimizes code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68274
--- Comment #2 from Matt Godbolt ---
Thanks for updating the bug. As a corollary, moving the unreachability above
the returns yields the same code as the non-unreachable: https://goo.gl/MdULOs
--
int test_with_unreach_First(Side side, const Foo &foo) {
if (side != Ask && side != Bid) __builtin_unreachable();
if (side == Bid) return foo.a;
return foo.b;
}
--
test_with_unreach_First(Side, Foo const&):
mov eax, DWORD PTR [rsi+4]
testedi, edi
cmove eax, DWORD PTR [rsi]
ret
--
For what it's worth I've been unable to coax either clang or icc (13.0.1
anyway) into the code I'd ideally like (the rsi+eax*4 case).
[Bug c++/68265] Arbitrary syntactic nonsense silently accepted after 'int (*){}' until the next close brace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68265 --- Comment #2 from Zack Weinberg --- This problem apparently goes back at least as far as 4.8. Stack Overflow people found a number of variations, please consult https://stackoverflow.com/questions/23033043/is-it-a-new-c11-style-of-comments https://stackoverflow.com/questions/23015482/strange-code-that-compiles-with-g
[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272 --- Comment #1 from joseph at codesourcery dot com --- This is not a standards conformance bug, on multiple grounds: * The C standard does not permit you to define your own copies of standard library functions (that is, functions in the standard you specified with -std=, e.g. -std=c99; -std= controls which built-in functions are present). All library function names are always reserved as identifiers with external linkage, whether or not you include the corresponding header. * You're using 4.9, which defaults to -std=gnu89. gnu89 inline semantics mean that plain "inline" functions *should* get out-of-line copies generated in each translation unit. For C99 inline semantics you need an appropriate -std option for versions before GCC 5 (which defaults to -std=gnu11). That said, it may be best anyway not to export such copies in C99 inlining mode, if the only extern declaration is the implicit built-in one. But you're well outside the standard if you try to do this.
[Bug libstdc++/68190] [5/6 Regression] iterator mix up with set::find and heterogenous lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Tue Nov 10 18:08:50 2015 New Revision: 230118 URL: https://gcc.gnu.org/viewcvs?rev=230118&root=gcc&view=rev Log: Fix return type of heterogeneous find for sets PR libstdc++/68190 * include/bits/stl_multiset.h (multiset::find): Fix return types. * include/bits/stl_set.h (set::find): Likewise. * testsuite/23_containers/map/operations/2.cc: Test find return types. * testsuite/23_containers/multimap/operations/2.cc: Likewise. * testsuite/23_containers/multiset/operations/2.cc: Likewise. * testsuite/23_containers/set/operations/2.cc: Likewise. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/stl_multiset.h branches/gcc-5-branch/libstdc++-v3/include/bits/stl_set.h branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/map/operations/2.cc branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/multimap/operations/2.cc branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/multiset/operations/2.cc branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/set/operations/2.cc
[Bug libstdc++/68190] [5/6 Regression] iterator mix up with set::find and heterogenous lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68190 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.3 --- Comment #13 from Jonathan Wakely --- Fixed.
[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158 --- Comment #12 from Jonathan Wakely --- Richard's patch changes the values returned by operator~ which is not desirable. To fix the underlying type to int in C++03 (so that all values of int will be valid values of the enumeration type) we can do: --- a/libstdc++-v3/include/bits/ios_base.h +++ b/libstdc++-v3/include/bits/ios_base.h @@ -74,7 +74,9 _S_adjustfield = _S_left | _S_right | _S_internal, _S_basefield = _S_dec | _S_oct | _S_hex, _S_floatfield= _S_scientific | _S_fixed, - _S_ios_fmtflags_end = 1L << 16 + _S_ios_fmtflags_end = 1L << 16, + _S_ios_fmtflags_max = __INT_MAX__, + _S_ios_fmtflags_min = ~(int)__INT_MAX__ }; inline _GLIBCXX_CONSTEXPR _Ios_Fmtflags @@ -114,7 +116,9 _S_in= 1L << 3, _S_out = 1L << 4, _S_trunc = 1L << 5, - _S_ios_openmode_end = 1L << 16 + _S_ios_openmode_end = 1L << 16, + _S_ios_openmode_max = __INT_MAX__, + _S_ios_openmode_min = ~(int)__INT_MAX__ }; inline _GLIBCXX_CONSTEXPR _Ios_Openmode @@ -152,7 +156,9 _S_badbit= 1L << 0, _S_eofbit= 1L << 1, _S_failbit = 1L << 2, - _S_ios_iostate_end = 1L << 16 + _S_ios_iostate_end = 1L << 16, + _S_ios_iostate_max = __INT_MAX__, + _S_ios_iostate_min = ~(int)__INT_MAX__ }; inline _GLIBCXX_CONSTEXPR _Ios_Iostate
[Bug libstdc++/56158] bad enum values computed by operator~ in ios_base.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56158 --- Comment #13 from Jonathan Wakely --- N.B. we could also get rid of the _S_ios_xxx_end enumerators, but that would break any code which (foolishly) refers to them, e.g. to suppress Clang's -Wswitch warnings. My suggestion assumes that __INT_MAX__ > (1 << 16), i.e. the compiler really will choose int as the underlying type, but I think that's OK.
[Bug go/68255] cgo-generated constructor not being called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-10 Ever confirmed|0 |1 --- Comment #2 from Ian Lance Taylor --- Thanks for the test case. I think we may as well always use --whole-archive. I sent out a patch for the gc toolchain as https://golang.org/cl/16775 . After that gets committed I will backport it to gccgo.
[Bug c++/68278] New: internal compiler error with C++14 polymorphic lambda and type alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68278
Bug ID: 68278
Summary: internal compiler error with C++14 polymorphic lambda
and type alias
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkeir at outlook dot com
Target Milestone: ---
Created attachment 36682
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36682&action=edit
C++14 file which produces the internal compiler error
The C++14 code below produces an internal compiler error in tsubst_decl, at
cp/pt.c:10836 when compiled using:
g++ -std=c++14 poly_type_lambda_bug.cpp
with GCC 5.2.0. I'm using Ubuntu 15.04 (vivid). It compilers and runs with
clang version 3.8.0 (trunk 252425).
int main(int argc, char *argv[])
{
auto f = []() { return 1; };
auto q = [=](auto g) {
using type = decltype(g(f()));
};
q([](int x){ return x; });
return 0;
}
[Bug go/68255] cgo-generated constructor not being called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Tue Nov 10 20:31:11 2015 New Revision: 230120 URL: https://gcc.gnu.org/viewcvs?rev=230120&root=gcc&view=rev Log: PR go/68255 cmd/go: always use --whole-archive for gccgo packages This is a backport of https://golang.org/cl/16775. This is, in effect, what the gc toolchain does. It fixes cases where Go code refers to a C global variable; without this, if the global variable was the only thing visible in the C code, the generated cgo file might not get pulled in from the archive, leaving the Go variable uninitialized. This was reported against gccgo as https://gcc.gnu.org/PR68255 . Reviewed-on: https://go-review.googlesource.com/16778 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/cmd/go/build.go
[Bug go/68255] cgo-generated constructor not being called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68255 Ian Lance Taylor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Should be fixed.
[Bug middle-end/68279] New: ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279 Bug ID: 68279 Summary: ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- with gcc version 6.0.0 20151110 (experimental) [trunk revision 230080] (GCC) > gfortran -c -O2 -floop-nest-optimize bug.f90 internal compiler error: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836 0x1252a13 create_pw_aff_from_tree ../../gcc/gcc/graphite-sese-to-poly.c:836 0x1252a13 create_pw_aff_from_tree ../../gcc/gcc/graphite-sese-to-poly.c:831 0x1258c9b add_condition_to_pbb ../../gcc/gcc/graphite-sese-to-poly.c:849 0x1258c9b add_conditions_to_domain ../../gcc/gcc/graphite-sese-to-poly.c:917 0x1258c9b add_conditions_to_constraints ../../gcc/gcc/graphite-sese-to-poly.c:940 0x1258c9b build_poly_scop(scop*) ../../gcc/gcc/graphite-sese-to-poly.c:1840 0x124773b graphite_transform_loops() ../../gcc/gcc/graphite.c:332 0x1247bd0 graphite_transforms ../../gcc/gcc/graphite.c:367 0x1247bd0 execute ../../gcc/gcc/graphite.c:444 Please submit a full bug report, > cat bug.f90 MODULE dbcsr_mm_accdrv INTEGER, SAVE :: accdrv_binning_nbins = 4096 INTEGER, SAVE :: accdrv_binning_binsize = 16 INTEGER, PARAMETER, PUBLIC :: dbcsr_ps_width = 7 CONTAINS SUBROUTINE stack_binning(params_in, params_out, stack_size) INTEGER, INTENT(IN) :: stack_size INTEGER, DIMENSION(dbcsr_ps_width, & stack_size), INTENT(OUT) :: params_out INTEGER, DIMENSION(dbcsr_ps_width, & stack_size), INTENT(IN):: params_in INTEGER, DIMENSION(accdrv_binning_nbins) :: bin_top INTEGER, DIMENSION(dbcsr_ps_width) :: val INTEGER, DIMENSION(dbcsr_ps_width, & accdrv_binning_binsize, & accdrv_binning_nbins) :: bin_arr DO i=1,stack_size val(:) = params_in(:,i) IF(bin_top(bin_id) > accdrv_binning_binsize) THEN params_out(:, top:top+bin_top(bin_id)-2) = bin_arr(:, 1:bin_top(bin_id)-1, bin_id) ENDIF bin_arr(:, bin_top(bin_id), bin_id) = val(:) bin_top(bin_id) = bin_top(bin_id) + 1 END DO END SUBROUTINE stack_binning
[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch, sebpop at gmail dot com Known to fail||6.0 --- Comment #1 from Joost VandeVondele --- trying to debug a '-O3 -floop-nest-optimize' miscompile of our code, I ran into this '-O2 -floop-nest-optimize' ICE.
