[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52531 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to janus from comment #7) Note that OpenMP 4.0 RC2 still lists polymorphic entities as unsupported, cf. http://openmp.org/wp/openmp-specifications/ Update: OpenMP has been officially released by now, but polymorphic variables continue to be unsupported.
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #4 from Chung-Ju Wu jasonwucj at gmail dot com --- (In reply to John David Anglin from comment #3) On 32-bit hppa-unknown-linux-gnu: Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-di agnostics-show-caret -fdiagnostics-color=never -O2 -S -o large-size-array-6.s(timeout = 300) spawn /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdir/gcc/ /home/ dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show -caret -fdiagnostics-color=never -O2 -S -o large-size-array-6.s /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/large-size-array-6.c:6:3: internal c ompiler error: in tree_low_cst, at tree.c:6805 0x7b8eab tree_low_cst(tree_node const*, int) ../../gcc/gcc/tree.c:6805 0x134c73 process_init_element(c_expr, bool, obstack*) ../../gcc/gcc/c/c-typeck.c:8351 0x1537b7 c_parser_initval ../../gcc/gcc/c/c-parser.c:4023 0x15306f c_parser_initelt ../../gcc/gcc/c/c-parser.c:3997 0x15306f c_parser_braced_init ../../gcc/gcc/c/c-parser.c:3779 0x158343 c_parser_initializer ../../gcc/gcc/c/c-parser.c:3737 0x158343 c_parser_declaration_or_fndef ../../gcc/gcc/c/c-parser.c:1651 0x15d883 c_parser_external_declaration ../../gcc/gcc/c/c-parser.c:1363 0x15e58b c_parser_translation_unit ../../gcc/gcc/c/c-parser.c:1251 0x15e58b c_parse_file() ../../gcc/gcc/c/c-parser.c:11000 0x1ae0ff c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1046 Same issue on my 32-bit nds32le-elf target: Executing on host: /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/build/build-nds32le-elf-newlib-v3/build-gcc-final/gcc/xgcc -B/home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/build/build -nds32le-elf-newlib-v3/build-gcc-final/gcc/ /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show-caret -fdiagno stics-color=never -O2 -S -DSIGNAL_SUPPRESS -o large-size-array-6.s (timeout = 600) spawn /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/build/build-nds32le-elf-newlib-v3/build-gcc-final/gcc/xgcc -B/home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/build/build-nds32le-elf- newlib-v3/build-gcc-final/gcc/ /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show-caret -fdiagnostics-color=ne ver -O2 -S -DSIGNAL_SUPPRESS -o large-size-array-6.s /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/testsuite/gcc.dg/large-size-array-6.c:6:3: internal compiler error: in tree_low_cst, at tree.c:6805 0x87b4492 tree_low_cst(tree_node const*, int) /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/tree.c:6805 0x8098f4c process_init_element(c_expr, bool, obstack*) /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-typeck.c:8351 0x80ab8ef c_parser_initval /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:4023 0x80ab78e c_parser_initelt^M /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:3997 0x80aaf25 c_parser_braced_init^M /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:3779 0x80aad75 c_parser_initializer^M /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:3737 0x80a70f4 c_parser_declaration_or_fndef /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:1651 0x80a69f5 c_parser_external_declaration /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:1363 0x80a665b c_parser_translation_unit /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:1251 0x80bc250 c_parse_file() /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/gcc/c/c-parser.c:11223 0x811af58 c_common_parse_file() /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/gcc-4.9.0/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. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #5 from Chung-Ju Wu jasonwucj at gmail dot com --- (In reply to Chung-Ju Wu from comment #4) (In reply to John David Anglin from comment #3) On 32-bit hppa-unknown-linux-gnu: [...] Same issue on my 32-bit nds32le-elf target: Executing on host: /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/build/build- nds32le-elf-newlib-v3/build-gcc-final/gcc/xgcc -B/home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/build/build -nds32le-elf-newlib-v3/build-gcc-final/gcc/ /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/ gcc-4.9.0/gcc/testsuite/gcc.dg/large-size-array-6.c -fno-diagnostics-show-caret -fdiagno stics-color=never -O2 -S -DSIGNAL_SUPPRESS -o large-size-array-6.s (timeout = 600) [...] 0x811af58 c_common_parse_file() /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/source-packages/ gcc-4.9.0/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. See http://gcc.gnu.org/bugs.html for instructions. I was using GCC trunk 20130724 Rev.201200. $ /home1/jasonwucj/WORKING/WORK-CONTRIBUTION/build-system-3/build/build-nds32le-elf-newlib-v3/build-gcc-final/gcc/xgcc --version xgcc (2013-07-24 nds32le-elf-newlib-v3) 4.9.0 20130724 (experimental) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/57942] g++-4.8.1 tries to instantiate wrong constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57942 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug fortran/57965] New: Allocation of derived type containing an allocatable character component segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57965 Bug ID: 57965 Summary: Allocation of derived type containing an allocatable character component segfaults Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ole.schuett at mat dot ethz.ch The following program compiles fine with gfortran 4.7.2, but when executed it segfaults. program crash TYPE mytype CHARACTER(LEN=42), ALLOCATABLE :: str_value END TYPE mytype TYPE(mytype), POINTER :: a = Null() ALLOCATE(a) end program crash
[Bug rtl-optimization/57960] LRA ICE building glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- But this is s390x, right? (Judging from the movstrictsi.)
[Bug c/57923] [4.9 Regression] ICE in handle_braces (gcc.c) at -O3 (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57923 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-24 CC||mpolacek at gcc dot gnu.org Known to work||4.8.1 Target Milestone|--- |4.9.0 Summary|ICE in handle_braces|[4.9 Regression] ICE in |(gcc.c) at -O3 (both 32-bit |handle_braces (gcc.c) at |and 64-bit modes) |-O3 (both 32-bit and 64-bit ||modes) Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed. G.c: In function ‘foo’: G.c:3:1: error: definition in block 3 follows the use foo (int **p) ^ for SSA_NAME: _46 in statement: _101 = _46 1; G.c:3:1: internal compiler error: verify_ssa failed 0xaa466c verify_ssa(bool) /home/marek/src/gcc/gcc/tree-ssa.c:1046 0x87d09e execute_function_todo /home/marek/src/gcc/gcc/passes.c:1598 0x87dabc execute_todo /home/marek/src/gcc/gcc/passes.c:1630 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 57923 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/57923] [4.9 Regression] ICE in handle_braces (gcc.c) at -O3 (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57923 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Actually, a dup of PR57393. *** This bug has been marked as a duplicate of bug 57393 ***
[Bug rtl-optimization/57662] [4.9 Regression] ICE: SIGSEGV in code_motion_process_successors with -fschedule-insns2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57662 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-24 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug rtl-optimization/57960] S/390: LRA ICE building glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Target||s390x-ibm-linux Host||s390x-ibm-linux Summary|LRA ICE building glibc |S/390: LRA ICE building ||glibc Build||s390x-ibm-linux --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org --- (In reply to Marek Polacek from comment #1) But this is s390x, right? (Judging from the movstrictsi.) Yes.
[Bug fortran/57966] New: Using a TBP to specify the shape of a dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 Bug ID: 57966 Summary: Using a TBP to specify the shape of a dummy argument Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stefan.mauerberger at gmail dot com Created attachment 30542 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30542action=edit minimal example Hi There! I am faced with some weired behavior. Because it is a little hard to describe I am providing an example: There is a DDT 'config_cls' whose pure TBP 'my_size' does nothing but returning 10 . TYPE config_cls CONTAINS PROCEDURE, NOPASS :: my_size END TYPE PURE INTEGER FUNCTION my_size() my_size = 10 END FUNCTION my_size In addition there is a subroutine 'my_sub' which expects a dummy argument of explicit shape 'config%my_size()'. SUBROUTINE my_sub( field ) REAL, INTENT(INOUT) :: field( config%my_size() ) !REAL, INTENT(INOUT), CONTIGUOUS :: field(:) ! Assumed shape works !REAL, INTENT(INOUT) :: field( my_size() ) ! works, too END SUBROUTINE my_sub As far as I can see this is valid Fortran code. However, gfortran complains that config%my_size() is not a function. Well, this is wrong (for non dummy arguments it works perfectly fine)! Attached, there is a minimal example. Compiling it with gfortran terminates with: test.f90:33.22: REAL :: field( config%my_size() ) 1 Error: 'my_size' at (1) should be a FUNCTION Any ideas? Cheers, Stefan Actually, ifort 12.1.6, nag 5.3.2 and pgfortran 13.4 are just fine.
[Bug rtl-optimization/57967] New: Incorrect code generated on ARM with -fexpensive-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57967 Bug ID: 57967 Summary: Incorrect code generated on ARM with -fexpensive-optimizations Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: daniel.blaukopf at oracle dot com Created attachment 30543 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30543action=edit Two functions, f1 and f2 should compile to almost the same result. The compiled code for f1 throws away the x0 and x1 parameters. In situations results of a computation that go into the top 16-bits of a 32-bit return value are optimized out. A small change to the source makes the problem go away. In the example provided, changing the order of function parameters provides the problem. - Reproduced on the ARM GCC 4.6.3 in Ubuntu 12.04 (both hard and soft float) by inspection of generated assembly - Reproduced on the Linaro GCC 4.7.2 unsupported 2012.09 toolchain from https://launchpad.net/linaro-toolchain-unsupported/, verified by inspection of generated assembly and by running a test case. + arm-linux-gnueabihf-gcc -v --save-temps -Wall -Wextra -shared -O -fexpensive-optimizations gcc-bug.c -o libgcc-bug.so Using built-in specs. COLLECT_GCC=arm-linux-gnueabihf-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/arm-linux-gnueabihf/include/c++/4.6.3 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include --with-headers=/usr/arm-linux-gnueabihf/include --with-libs=/usr/arm-linux-gnueabihf/lib Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared' '-O' '-fexpensive-optimizations' '-o' 'libgcc-bug.so' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -E -quiet -v -imultilib . -imultiarch arm-linux-gnueabihf gcc-bug.c -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -Wall -Wextra -fexpensive-optimizations -O -fpch-preprocess -fstack-protector -o gcc-bug.i ignoring duplicate directory /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../../arm-linux-gnueabihf/include ignoring nonexistent directory /usr/include/arm-linux-gnueabihf #include ... search starts here: #include ... search starts here: /usr/lib/gcc/arm-linux-gnueabihf/4.6/include /usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed /usr/arm-linux-gnueabihf/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared' '-O' '-fexpensive-optimizations' '-o' 'libgcc-bug.so' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -fpreprocessed gcc-bug.i -quiet -dumpbase gcc-bug.c -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -auxbase gcc-bug -O -Wall -Wextra -version -fexpensive-optimizations -fstack-protector -o gcc-bug.s GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (arm-linux-gnueabihf) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (Ubuntu/Linaro 4.6.3-1ubuntu5) version 4.6.3 (arm-linux-gnueabihf) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: cc9c163e1be35f3de7fa1357bc204e65 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-shared' '-O' '-fexpensive-optimizations' '-o' 'libgcc-bug.so' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb' /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../../arm-linux-gnueabihf/bin/as -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -meabi=5 -o gcc-bug.o gcc-bug.s
[Bug rtl-optimization/57967] Incorrect code generated on ARM with -fexpensive-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57967 --- Comment #1 from Daniel Blaukopf daniel.blaukopf at oracle dot com --- Created attachment 30544 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30544action=edit Test case that can be run with libgcc-bug.so to show the failure
[Bug rtl-optimization/57967] Incorrect code generated on ARM with -fexpensive-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57967
--- Comment #2 from Daniel Blaukopf daniel.blaukopf at oracle dot com ---
This code:
int f1(int x0, int y0, int z0, int x1, int y1, int z1) {
int xx = ((x0 16) + (x1 - x0) * 0x1234 + 0x8000) 16;
int yy = ((y0 16) + (y1 - y0) * 0x2345 + 0x8000) 16;
int zz = ((z0 16) + (z1 - z0) * 0x3456 + 0x8000) 16;
return (xx 16) | (yy 8) | zz;
}
Compiles (incorrectly) to:
f1:
@ args = 8, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrr0, [sp, #4]
subsr0, r0, r2
movwr3, #13398
mulr0, r3, r0
addr2, r0, r2, lsl #16
ldrr3, [sp, #0]
subsr3, r3, r1
movwr0, #9029
mulr3, r0, r3
addr1, r3, r1, lsl #16
addr1, r1, #32768
asrr1, r1, #16
lslr1, r1, #8
addr0, r2, #32768
orrr0, r1, r0, asr #16
bxlr
This almost identical code:
int f2(int x0, int x1, int y0, int y1, int z0, int z1) {
int xx = ((x0 16) + (x1 - x0) * 0x1234 + 0x8000) 16;
int yy = ((y0 16) + (y1 - y0) * 0x2345 + 0x8000) 16;
int zz = ((z0 16) + (z1 - z0) * 0x3456 + 0x8000) 16;
return (xx 16) | (yy 8) | zz;
}
Compiles (correctly) to:
f2:
@ args = 8, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
push{r4, r5}
ldrr4, [sp, #8]
subsr3, r3, r2
movwr5, #9029
mulr3, r5, r3
addr2, r3, r2, lsl #16
addr2, r2, #32768
asrr2, r2, #16
subsr1, r1, r0
movwr3, #4660
mulr1, r3, r1
addr0, r1, r0, lsl #16
addr0, r0, #32768
asrr0, r0, #16
lslr0, r0, #16
orrr2, r0, r2, lsl #8
ldrr0, [sp, #12]
subsr0, r0, r4
movwr3, #13398
mulr0, r3, r0
addr4, r0, r4, lsl #16
addr0, r4, #32768
orrr0, r2, r0, asr #16
pop{r4, r5}
bxlr
[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-24 CC||janus at gcc dot gnu.org Summary|Using a TBP to specify the |[OOP] Using a TBP to |shape of a dummy argument |specify the shape of a ||dummy argument Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- (In reply to stefan.mauerberger from comment #0) Hi There! Hi! I am faced with some weired behavior. Because it is a little hard to describe I am providing an example: ... which is anyway a much better idea than trying to describe it. Attached, there is a minimal example. Compiling it with gfortran terminates with: test.f90:33.22: REAL :: field( config%my_size() ) 1 Error: 'my_size' at (1) should be a FUNCTION Any ideas? Seems like you hit a bug. I can reproduce it with 4.7, 4.8 and trunk. Slightly reduced test case: MODULE my_mod IMPLICIT NONE TYPE config_cls CONTAINS PROCEDURE, NOPASS :: my_size END TYPE TYPE(config_cls) :: config CONTAINS PURE INTEGER FUNCTION my_size() my_size = 10 END FUNCTION SUBROUTINE my_sub( field ) REAL :: field( config%my_size() ) END SUBROUTINE END MODULE Thanks for reporting ... Cheers, Janus
[Bug rtl-optimization/57968] New: MODE_EXIT switches inserted too late
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57968 Bug ID: 57968 Summary: MODE_EXIT switches inserted too late Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amylaar at gcc dot gnu.org I see a miscompilation of ___muldi3 for epiphany-elf; the witch to MODE_EXIT is done at the start of the exit block, even though it contains instructions that require a different mode. The return register on the epiphany is not likely spilled, and a large register file gives lots of freedom to do optimizations; when optimizig ___muldi3, at end end the return value is not so much copied as calculated piecemeal. There is some existing code in compute_pre_exit that is supposed to preserve computations that need a non-exit mode, but the way it is placed means it is only active when the immediate result is part of the return register.
[Bug rtl-optimization/57968] MODE_EXIT switches inserted too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57968 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- A patch is here: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01081.html
[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
--- Comment #2 from janus at gcc dot gnu.org ---
Draft patch (not regtested yet):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 201038)
+++ gcc/fortran/resolve.c(working copy)
@@ -5638,14 +5638,6 @@ resolve_compcall (gfc_expr* e, const char **name)
gfc_actual_arglist* newactual;
gfc_symtree* target;
- /* Check that's really a FUNCTION. */
- if (!e-value.compcall.tbp-function)
-{
- gfc_error ('%s' at %L should be a FUNCTION,
- e-value.compcall.name, e-where);
- return false;
-}
-
/* These must not be assign-calls! */
gcc_assert (!e-value.compcall.assign);
@@ -5661,6 +5653,15 @@ resolve_compcall (gfc_expr* e, const char **name)
return false;
gcc_assert (!e-value.compcall.tbp-is_generic);
+ /* Check that it's really a FUNCTION. */
+ if (!e-value.compcall.tbp-function
+ !e-value.compcall.tbp-u.specific-n.sym-attr.function)
+{
+ gfc_error ('%s' at %L should be a FUNCTION,
+ e-value.compcall.name, e-where);
+ return false;
+}
+
/* Take the rank from the function's symbol. */
if (e-value.compcall.tbp-u.specific-n.sym-as)
e-rank = e-value.compcall.tbp-u.specific-n.sym-as-rank;
[Bug target/57969] New: AIX data alignment behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57969 Bug ID: 57969 Summary: AIX data alignment behaviour Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gseanmcg at gmail dot com Target: powerpc-ibm-aix Using gcc 4.8.1 on AIX, should a 32-byte static data alignment declaration such as the following work as intended by the author? static float __attribute__((aligned(32))) data_with_32byte_alignment[512]; I know that Altivec only requires 16-byte alignment, and I'm not certain if this is a bug, as I've also seen some documentation online suggesting it could an ABI limitation on AIX. Perhaps someone can correct me and send me on my way if this is the case.
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #5 from David Binderman dcb314 at hotmail dot com --- Created attachment 30545 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30545action=edit source code patch This patch seems to shut up cppcheck. I did a bootstrap and that seemed ok. It seems good to go to me.
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #6 from David Binderman dcb314 at hotmail dot com --- (In reply to Paolo Carlini from comment #4) For a quicker review, I would recommend CC-ing Jason and adding [C++ Patch] to the subject line. I'm not on the inner wheel for C++ patches, so I am guessing that you mean Jason Merrill. If so, is jason at redhat dot com a good email address for him ?
[Bug rtl-optimization/57662] [4.9 Regression] ICE: SIGSEGV in code_motion_process_successors with -fschedule-insns2 -fselective-scheduling2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57662 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- In sel-sched.c, /* We have simplified the control flow below this point. In this case, the iterator becomes invalid. We need to try again. */ if (BLOCK_FOR_INSN (insn)-index != old_index || EDGE_COUNT (bb-succs) != old_succs) the BLOCK_FOR_INSN (insn) is NULL, so we segfault; the call to code_motion_path_driver somehow changes the insn to (jump_insn/v 203 0 0 (set (pc) (label_ref 202)) -1 (nil) - 202)
[Bug other/57970] New: segfault in sched-deps.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57970 Bug ID: 57970 Summary: segfault in sched-deps.c Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: colanderman at gmail dot com Created attachment 30546 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30546action=edit Patch Symptom: Segfault in sched-deps.c when compiling a large auto-generated C file: ==3363== Invalid read of size 8 ==3363==at 0x95A41D: sched_analyze_1 (sched-deps.c:2479) ==3363==by 0x95D182: sched_analyze_insn (sched-deps.c:2859) ==3363==by 0x95E636: deps_analyze_insn (sched-deps.c:3505) ==3363==by 0x95E7F1: sched_analyze (sched-deps.c:3653) ==3363==by 0x6EC4F8: sched_rgn_compute_dependencies (sched-rgn.c:2702) ==3363==by 0x6EF582: schedule_insns (sched-rgn.c:2915) ==3363==by 0x89E237: tilegx_reorg (tilegx.c:4710) ==3363==by 0x6E0699: rest_of_handle_machine_reorg (reorg.c:4183) ==3363==by 0x69F5BF: execute_one_pass (passes.c:2084) ==3363==by 0x69FA30: execute_pass_list (passes.c:2139) ==3363==by 0x69FA44: execute_pass_list (passes.c:2140) ==3363==by 0x69FA44: execute_pass_list (passes.c:2140) ==3363== Address 0x8 is not stack'd, malloc'd or (recently) free'd Cause: deps-pending_read_insns and deps-pending_read_mems are getting out of sync. (Hence the NULL pointer access at sched-deps.c:2479.) Fix: The conditions !deps-readonly under which deps-pending_read_mems is freed in flush_pending_lists() should be changed to !deps-readonly !DEBUG_INSN_P (insn) to match the condition deps-readonly || DEBUG_INSN_P (insn) under which deps-pending_read_insns is not freed in add_dependence_list_and_free(). Patch attached. Unfortunately I cannot provide a test case, as I have only been able to reproduce the crash with a very large (auto-generated) proprietary C file. The bug seems to exist in the source code of at least 4.6.3 as well, though I have not been able to trigger it therein.
[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to janus from comment #2) Draft patch (not regtested yet): Seems to survive the regtest without any failures (except for round_4.f90, which is unrelated).
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, or at gcc.gnu.org
[Bug rtl-optimization/57960] S/390: LRA ICE building glibc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com --- (In reply to Andreas Krebbel from comment #2) (In reply to Marek Polacek from comment #1) But this is s390x, right? (Judging from the movstrictsi.) Yes. Thanks, Andrew. I've reproduced it. I guess a fix will be ready on this week as the bug is in a sensitive part of LRA and the fix will need a lot of testing on a few machines.
[Bug libstdc++/53622] C++11 regex captures extra characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53622 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Should be fixed by http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00643.html
[Bug libstdc++/57173] Regex match group contain extraneous character...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57173 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Should be fixed by http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00643.html
[Bug libstdc++/57513] std::regex_token_iterator fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57513 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.0.
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- If we have a straightforward explanation for why the very weird code isn't causing problems, I think the fix almost qualifies as obvious, if properly tested. Do we? Does it only amount to a small memory leak or a small buffer overrun, something similar? In any case, yes, gcc-patches@ CC Jason Merrill (there aren't *that* many C++ maintainers on gcc-patches named Jason ;)
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-24 Ever confirmed|0 |1 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- If we have a straightforward explanation for why the very weird code isn't causing problems, I think the fix almost qualifies as obvious, if properly tested. Do we? Does it only amount to a small memory leak or a small buffer overrun, something similar? In any case, yes, gcc-patches@ CC Jason Merrill (there aren't *that* many C++ maintainers on gcc-patches named Jason ;)
[Bug rtl-optimization/57967] [4.7 regresssion] Incorrect code generated on ARM with -fexpensive-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57967 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-24 Known to work||4.8.2 Summary|Incorrect code generated on |[4.7 regresssion] Incorrect |ARM with|code generated on ARM with |-fexpensive-optimizations |-fexpensive-optimizations Ever confirmed|0 |1 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- This appears to be a bug in combine. My suspicion lies with the new 4-way combine code that was added around gcc-4.6. Note that gcc-4.6 is no-longer being maintained. The problem seems to be fixed in 4.8 so a bisect might indicate a fix.
[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #33 from Martin Jambor jamborm at gcc dot gnu.org --- I can confirm that one call of resid now gets inlined on the branch even on x86_64 (I'm confused why, the dump seems to suggest all call sites would violate param max-inline-insns-auto limit but then one gets inlined anyway) and we are 5.6% slower than if we also specify --param inline-min-speedup=17 (in addition to -Ofast). This is not a regression from 4.8.0. When I checked out the revision with that tag, I got exactly the same inlining and pretty much the same run time. As far as the cause of the slowdown is concerned, my simple greps suggest that vectorization happens anyway but as I wrote in comment 24, if we loose restrict we also lose opportunity to do hoisting of a loop invariant load so it is still likely that a lost restrict is the issue anyway.
[Bug libstdc++/57513] std::regex_token_iterator fails to link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57513 timshen at gcc dot gnu.org changed: What|Removed |Added CC||timshen at gcc dot gnu.org --- Comment #3 from timshen at gcc dot gnu.org --- Should be fixed by http://gcc.gnu.org/ml/gcc-cvs/2013-07/msg00599.html
[Bug c++/57880] cp/parser.c: 6 * missing break ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57880 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- I had a closer look and I don't think the proposed patchlet is correct: for, eg, case CPP_WSTRING we want string_len = 3 and then fall through to the checks.
[Bug c++/57971] New: Improve copy elision when returning structs by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57971
Bug ID: 57971
Summary: Improve copy elision when returning structs by value
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Hi all,
In the testcase below, bar() and baz() perform copy elision as expected, but
blah() does not, in spite of its being functionally identical to baz():
#include cstdio
struct foo {
foo() { printf(make\n); }
foo(foo const ) { printf(copy\n); }
void frob() { printf(frob\n); }
};
foo bar(bool) {
foo f;
f.frob();
return f;
}
foo baz(bool mknew) {
if (mknew)
return foo();
return bar(mknew);
}
foo blah(bool mknew) {
if (mknew)
return foo();
foo f = bar(mknew);
return f;
}
int main() {
printf(*** bar ***\n);
bar(false);
printf(*** baz ***\n);
baz(false);
printf(*** blah ***\n);
blah(false);
}
Output is:
$ g++ -Wall bug.cpp ./a.out
*** bar ***
make
frob
*** baz ***
make
frob
*** blah ***
make
frob
copy
I assume that bar() and baz() exploit the named and unnamed return value
optimizations, respectively, but blah() is missed because it needs both
optimizations together.
[Bug fortran/53309] Unnecessary temporary array creation in subroutine call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53309 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- The runtime test is done by _gfortran_internal_pack. -Warray-temporaries creates the warning if this is called. If you want to know if a temporary has actually been created, use -fcheck-array-temporaries. Does this answer your concern?
[Bug tree-optimization/57972] New: Statement sinking algorithm should just be replaced with GCM algorithm's late scheduler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57972
Bug ID: 57972
Summary: Statement sinking algorithm should just be replaced
with GCM algorithm's late scheduler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dberlin at gcc dot gnu.org
The store sinking algorithm in tree-ssa-sink.c has grown to the point where it
is *almost*, but not exactly, equivalent to the GCM's schedule_late phase
algorithm presented by Cliff Click in PLDI '95
(http://www.cs.washington.edu/education/courses/cse501/06wi/reading/click-pldi95.pdf)
The current algorithm is basically:
For each bb in post-dominator order:
For each statement in reverse:
find sink location using nearest common dominators of users.
compute validity
move to sink location
This requires computing post dominators, among other things.
The GCM algorithm is, basically:
FOr each unmovable instruction I
mark I as pinned
I.visit = true
for each use U of I
schedule_late (U)
For every other instruction I
schedule_late (I)
schedule_late is essentially the same as statement_sink_location + movement,
with the different that it recursively calls itself to on the users to move
them first.
//Find latest legal block for instruction i
Schedule_Late( instruction i ) {
if i.visit = True then
return;
i.visit:= True;
Block lca = empty
forall uses y of i do {
Schedule_Late( y );
Block use := y.block;
if y is a PHI then {
// Reverse dependence edge from i to y
Pick j so that the jth input of y is i
// Use matching block from CFG
use := y.block.CFG_pred[j];
}
lca := Find_LCA( lca, use );
}
// You can place i in lca.
}
This should do slightly better than GCC's algorithm, and not require computing
postdominators explicitly.
The LCA computation performed is equivalent to using nearest_common_dominator.
[Bug c++/57973] New: incorrect access check for protected member of template base with using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973 Bug ID: 57973 Summary: incorrect access check for protected member of template base with using Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rogero at howzatt dot demon.co.uk Created attachment 30547 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30547action=edit sample program -- I believe this should compile. In a template class where a protected member of a template base class is the subject of a using declaration, atempting to form pointer-to-member fails. I have tested with: mingw g++ (niXman build) 4.7.0 20120203 (experimental) www.ideone.com (gcc 4.7.2) www.godbolt.com (gcc 4.4.7, 4.5.3, 4.6.4, 4.7.3, 4.8.1) the program fails to compile on each with these errors: prog.cpp: In instantiation of ‘bool DT::testB() const [with T = int]’: prog.cpp:37:12: required from here prog.cpp:22:17: error: ‘using BT::bptr’ is inaccessible prog.cpp:25:18: error: within this context I beleive the code is correct, and it is accepted by: clang 3.0.6 icc 13.0 msvc 12
[Bug c++/57974] New: std::pow(std::complexlong double(0),1) returns (-nan,-nan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
Bug ID: 57974
Summary: std::pow(std::complexlong double(0),1) returns
(-nan,-nan)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: henner.sudek at gmail dot com
Created attachment 30548
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30548action=edit
the preprocessed file (*.i*) that triggers the bug
The following program gives the wrong result when compiled with the options
given below. Removing any of the compiler options gives the expected result
(0,0). I was able to reproduce the error with gcc-4.7.3, 4.8.1 and 4.9.0.
$ cat complex.cpp
#include complex
#include iostream
int main(){
std::cerr std::pow(std::complexlong double(0),1) std::endl;
}
$ c++ -std=c++11 -fno-math-errno -funsafe-math-optimizations complex.cpp
$ ./a.out
(-nan,-nan)
$ /home/henner/gcc-4.9.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/henner/gcc-4.9.0/bin/g++
COLLECT_LTO_WRAPPER=/home/henner/gcc-4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/henner/gcc-4.9.0
Thread model: posix
gcc version 4.9.0 20130724 (experimental) (GCC)
[Bug c++/57973] incorrect access check for protected member of template base with using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.2, 4.9.0 Resolution|--- |FIXED --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Already fixed in 4.8.2 and mainline.
[Bug c++/57975] New: Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975
Bug ID: 57975
Summary: Core dump caused by linking with -lpthread
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michi at triodia dot com
The following code works as expected when compiling with
c++ -g --std=c++11 test.cpp
The program hangs until it is interrupted.
When I compile the same code with
c++ -g --std=c++11 test.cpp -lpthread
I get a segfault in wait():
Program received signal SIGSEGV, Segmentation fault.
__pthread_mutex_unlock_usercnt (mutex=0x0, decr=0) at pthread_mutex_unlock.c:37
37pthread_mutex_unlock.c: No such file or directory.
(gdb) bt
#0 __pthread_mutex_unlock_usercnt (mutex=0x0, decr=0) at
pthread_mutex_unlock.c:37
#1 0x77bc8c17 in pthread_cond_wait@@GLIBC_2.3.2 ()
at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:94
#2 0x779698ec in
std::condition_variable::wait(std::unique_lockstd::mutex) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00400a69 in main () at test.cpp:13
Here is the complete source:
#include condition_variable
#include mutex
int main(int, char**)
{
bool predicate = false;
std::mutex mutex;
std::condition_variable condvar;
std::unique_lockdecltype(mutex) lock;
while (!predicate)
{
condvar.wait(lock);
}
}
Compiler version is
gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3
running on Ubuntu Raring.
libpthread is:
libpthread.so.0 (libc6,x86-64, OS ABI: Linux 2.6.24) =
/lib/x86_64-linux-gnu/libpthread.so.0
[Bug c++/57975] Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975 Michi Henning michi at triodia dot com changed: What|Removed |Added Version|unknown |4.7.3 --- Comment #1 from Michi Henning michi at triodia dot com --- uname reports: Linux ubuntu 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[Bug c++/57973] incorrect access check for protected member of template base with using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57973 --- Comment #2 from Roger Orr rogero at howzatt dot demon.co.uk --- Thank you. Aoplogies for the noise.
[Bug fortran/57965] Allocation of derived type containing an allocatable character component segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57965 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org Depends on||57959 Known to fail||4.5.3, 4.8.1, 4.9.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Instead of nullifying (internally) the str_value, the compiler tries to set the unallocated string to the value 0 followed by space padding. The call path is: gfc_trans_structure_assign - gfc_trans_subcomponent_assign - gfc_trans_scalar_assign - gfc_trans_string_copy. I think the issue is effectively the same as PR57959
[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57966 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to janus from comment #3) Seems to survive the regtest without any failures (except for round_4.f90, which is unrelated). Regarding: round_4.f90 with GLIBC (e.g. Linux), it is expected to fail with GLIBC 2.17 as those ignore the rounding; cf. http://sourceware.org/bugzilla/show_bug.cgi?id=3479
[Bug middle-end/57974] std::pow(std::complexlong double(0),1) returns (-nan,-nan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Component|c++ |middle-end --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- IMHO the most interesting bit is that it only happens for long double. Anyway, this is neither C++ library nor front-end, either middle-end or libc, likely the former because on my machine neither clang++ nor icc has the issue while the underlying libc is the same glibc. Anyway, reduced: __builtin_expl (- 1 / 0.0)
[Bug c++/57975] Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|michi at triodia dot com |jwakely.gcc at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Jon, can you help me with this?
[Bug fortran/53309] Unnecessary temporary array creation in subroutine call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53309 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Depends on||57959 Resolution|--- |WORKSFORME --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Let's close this as WONTFIX. -Warray-temporaries warns if the compiler adds code for temporaries. In case of actual arguments, there is a run-time check, which only does the copy-in/copy-out if the variable is noncontiguous. As Thomas wrote, you can use -fcheck-array-temporaries which prints at runtime a warning if the copy-in/copy-out actually happened. If the compiler knows that the actual argument is contiguous, it can avoid the copy-in altogether. For your example, simply mark the dummy argument a of sub_wrap as CONTIGUOUS (or use an explicit/assumed-size array instead).
[Bug fortran/53309] Unnecessary temporary array creation in subroutine call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53309 --- Comment #3 from Rich Townsend townsend at astro dot wisc.edu --- Thanks for the explanation about -Warray-temporaries vs. -fcheck-array-temporaries -- got it! Might be worth changing the output text from the former to something like Warning: Array temporary might be created at (1)
[Bug middle-end/57974] std::pow(std::complexlong double(0),1) returns (-nan,-nan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Or, more elegantly: __builtin_expl (-__builtin_huge_vall ())
[Bug middle-end/57974] std::pow(std::complexlong double(0),1) returns (-nan,-nan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug libstdc++/57975] Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-24 Component|c++ |libstdc++ Ever confirmed|0 |1
[Bug libstdc++/57975] Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- It only works without -lpthread because the implementation of pthread_mutex_lock() in libc.so is a no-op, so your program is a busy loop that spins using 100% CPU, not waiting patiently on the condvar. When you link to libpthread you get a real implementation of pthread_mutex_lock that fails because when you call condvar.wait(lock) you fail to meet the precondition that lock.owns_lock() is true, so it's undefined behaviour.
[Bug libstdc++/57975] Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks!
[Bug libstdc++/57975] Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- I am working (slowly) on some additional Debug Mode checks in mutex, condition_variable etc. so at some point you'll be able to debug this with -D_GLIBCX_DEBUG
[Bug libstdc++/57976] New: Missing time_get::get() functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57976 Bug ID: 57976 Summary: Missing time_get::get() functions Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: lcarreon at bigpond dot net.au The standard facet time_get is missing the get() functions. According to the GCC 4.7 C++11 Implementation Status, Section 22.4.5.1 of the standard library is completely implemented. However, the time_get::get() functions are missing therefore it isn't complete.
[Bug libstdc++/57976] Missing time_get::get() functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57976 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- The status page needs a tweak: it's well known that isn't implemented, for the simple reason that completing the C++11 time_get means adding the do_get virtual, which didn't exist in C++98, and doing that breaks the ABI.
[Bug libstdc++/57976] Missing time_get::get() functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57976 --- Comment #2 from Leo Carreon lcarreon at bigpond dot net.au --- Is there a plan to implement those functions? If yes, in which version?
[Bug libstdc++/57976] Missing time_get::get() functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57976 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- When we break the ABI. Likely in the release series after 4.9.
[Bug libstdc++/57976] Missing time_get::get() functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57976 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Same issue, really. *** This bug has been marked as a duplicate of bug 54354 ***
[Bug libstdc++/57975] Core dump caused by linking with -lpthread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57975 --- Comment #6 from Michi Henning michi at triodia dot com --- How embarrassing. The joys of default constructors :-( Stupid mistake of mine.
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||lcarreon at bigpond dot net.au --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57976 has been marked as a duplicate of this bug. ***
[Bug libstdc++/57914] Memory leak in __cxa_thread_atexit when using thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57914 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed for 4.9.0.
[Bug libstdc++/57976] Missing time_get::get() functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57976 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- I have adjusted status_cxx2011.xml
[Bug c/57821] 'array is too large' error is missing when sizetype overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57821 --- Comment #6 from Chung-Ju Wu jasonwucj at gmail dot com --- (In reply to Chung-Ju Wu from comment #4) (In reply to John David Anglin from comment #3) On 32-bit hppa-unknown-linux-gnu: Same issue on my 32-bit nds32le-elf target: Interesting. With our target testing results: Target is nds32le-unknown-elf Host is x86_64-unknown-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg02149.html Target is nds32le-unknown-elf Host is i686-pc-linux-gnu http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg02147.html Check gcc test summary, it shows that the problem only appears on 32-bit host. John, does your case happen on 32-bit only as well? :)
[Bug c++/57977] New: zero-length const array in union prohibits default copy xtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977
Bug ID: 57977
Summary: zero-length const array in union prohibits default
copy xtor
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.santos at pobox dot com
#include iostream
union a {
struct {
const char string[0];
} b;
};
int main(int argc, char *argv[]) {
std::cout size = sizeof(union a) std::endl;
return 0;
}
Produces:
bug.cpp:6:4: error: member ‘a::anonymous struct a::b’ with copy assignment
operator not allowed in union
bug.cpp:6:4: note: unrestricted unions only available with -std=c++11 or
-std=gnu++11
So the zero-length array is, of course, a gcc extension. I believe it is a bug
because it is zero-sized and no code needs to be generated to copy union
a::b::string.
My justification for using this is to aid in const correctness. I actually use
this in C in a kernel module where I create and populate it once and then
access it several times, so I just cast it as non-const when I populate it. I
prefer to use the exact same header files for kernel userland where possible.
[Bug c++/57977] zero-length const array in union prohibits default copy xtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57977 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- It is not the zero length which is causing the copy constructor to be created but rather the const part which causes the copy constructor to happen.
