[Bug c/58303] C99 union initializers new union members clobber earlier data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58303 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- In C99, only one union member may be active at a time, assignment to one of union members invalidates all the others. So I don't see anything wrong on this.
[Bug c/58303] C99 union initializers new union members clobber earlier data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58303 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- An initializer for an union is a single value. In C89, only the first member of a union can be initialized; in C99/C11 you can use the designated initializers to specify which member to initialize, but still only a single member of an union can be initialized.
[Bug c++/58300] ICE: in decide_is_symbol_needed, at cgraphunit.c:233 with -fvtable-verify=preinit on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58300 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c++/58300] ICE: in decide_is_symbol_needed, at cgraphunit.c:233 with -fvtable-verify=preinit on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58300 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with VTV merge: r201555.
[Bug c++/58300] ICE: in decide_is_symbol_needed, at cgraphunit.c:233 with -fvtable-verify=preinit on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58300 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- decide_is_symbol_needed has /* Double check that no one output the function into assembly file early. */ but it gets function_decl 0x7fedaeb5f500 _GLOBAL__sub_I.00099_vt.C type function_type 0x7fedaea12bd0 type void_type 0x7fedaea02bd0 void VOID align 8 symtab 0 alias set -1 canonical type 0x7fedaea02bd0 pointer_to_this pointer_type 0x7fedaea02c78 QI size integer_cst 0x7fedaea04180 constant 8 unit size integer_cst 0x7fedaea041a0 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7fedaea12bd0 arg-types tree_list 0x7fedae9f5b18 value void_type 0x7fedaea02bd0 void used nothrow static preserve decl_5 QI file vt.C line 4 col 2 align 8 initial block 0x7fedaeb67050 result result_decl 0x7fedaeb64000 D.2221 type void_type 0x7fedaea02bd0 void ignored VOID file vt.C line 4 col 2 align 8 context function_decl 0x7fedaeb5f500 _GLOBAL__sub_I.00099_vt.C full-name (static initializers for vt.C) pending-inline-info 0x7fedaeb60480 (mem:QI (symbol_ref:DI (_GLOBAL__sub_I.00099_vt.C) [flags 0x3] function_decl 0x7fedaeb5f500 _GLOBAL__sub_I.00099_vt.C) [0 S1 A8]) struct-function 0x7fedae9f7140
[Bug middle-end/57287] [4.9 Regression] Bogus uninitialized warning with abnormal control flow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 --- Comment #22 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 3 Sep 2013, amylaar at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #21 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) Added: trunk/gcc/testsuite/gcc.dg/pr57287-2.c Why is that using __sigsetjmp ? That's not a standard function. E.g. newlib doesn't have it. Sorry, I forgot to change it to setjmp. Done now.
[Bug middle-end/57287] [4.9 Regression] Bogus uninitialized warning with abnormal control flow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 --- Comment #23 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Sep 3 07:53:05 2013 New Revision: 202197 URL: http://gcc.gnu.org/viewcvs?rev=202197root=gccview=rev Log: 2013-09-03 Richard Biener rguent...@suse.de PR middle-end/57287 * gcc.dg/pr57287-2.c: Use setjmp, not __sigsetjmp. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr57287-2.c
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #18 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- I have found that tree-fre, tree-pre and tree-dse have to be disabled in order to generate correctly working code at all optimization levels (both C and FORTRAN). I'm happy with this workaround, so thank you for all suggestions.
[Bug lto/58298] [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58298 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #2 from Bernd Edlinger bernd.edlinger at hotmail dot de --- same error for gcc.c-torture/execute/align-nest.c
[Bug lto/58285] ICE in lto_output_tree, at lto-streamer-out.c:1318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285 --- Comment #3 from Jan Smets jan.sm...@alcatel-lucent.com --- vxworks target : . vs $ in asm names.
[Bug debug/56805] DW_TAG_typedef missing when -fdebug-types-section is used (and -fno-eliminate-unused-debug-types)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56805 --- Comment #7 from Jan Smets jan.sm...@alcatel-lucent.com --- Ping
[Bug libstdc++/58302] compilation error : std::negative_binomial_distribution::operator(e, p)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58302 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks. A pretty stupid typo, I'll fix it ASAP.
[Bug middle-end/58270] Wrong code while accessing trailing array elements in a global common structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target|i386-pc-linux |
Status|WAITING |NEW
CC||rguenth at gcc dot gnu.org
Component|fortran |middle-end
Host|i386-pc-linux |
Summary|Wrong code while accessing |Wrong code while accessing
|array elements in a global |trailing array elements in
|structure |a global common structure
Known to fail||4.9.0
--- Comment #19 from Richard Biener rguenth at gcc dot gnu.org ---
DECL_COMMONs could be special-cased in places that look at DECL_SIZE (I'll
declare this a QOI issue). Or all decls that do not bind locally. The
place that would fix tree-fre, tree-pre and tree-dse is in
get_ref_base_and_extent where it does
if (DECL_P (exp))
{
/* If maxsize is unknown adjust it according to the size of the
base decl. */
if (maxsize == -1
host_integerp (DECL_SIZE (exp), 1))
maxsize = TREE_INT_CST_LOW (DECL_SIZE (exp)) - hbit_offset;
}
else if (CONSTANT_CLASS_P (exp))
{
/* If maxsize is unknown adjust it according to the size of the
base type constant. */
if (maxsize == -1
host_integerp (TYPE_SIZE (TREE_TYPE (exp)), 1))
maxsize = TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (exp))) - hbit_offset;
}
In its general processing the function treats all trailing arrays as possibly
of undefined size.
Note that because -fcommon is still the default for all C dialects the
impact of changing the above for example in the simple !DECL_COMMON (exp)
way is unknown. -fcommon is a source of interesting bugs.
[Bug lto/58285] ICE in lto_output_tree, at lto-streamer-out.c:1318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||mips-vxworks Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-03 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. tree-streamer-out.c misses to include tm.h, mine.
[Bug middle-end/58270] Wrong code while accessing trailing array elements in a global common structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #20 from Dominique d'Humieres dominiq at lps dot ens.fr --- This looks like a duplicate of pr50463 (and may be more).
[Bug middle-end/58270] Wrong code while accessing trailing array elements in a global common structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #21 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr53086 also.
[Bug lto/58285] ICE in lto_output_tree, at lto-streamer-out.c:1318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug lto/58285] ICE in lto_output_tree, at lto-streamer-out.c:1318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Sep 3 09:48:27 2013 New Revision: 202202 URL: http://gcc.gnu.org/viewcvs?rev=202202root=gccview=rev Log: 2013-09-03 Richard Biener rguent...@suse.de PR lto/58285 * tree-streamer-out.c: Include tm.h. * Makefile.in (tree-streamer-out.o): Depend on $(TM_H). Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/tree-streamer-out.c
[Bug tree-optimization/57656] [4.7/4.8/4.9 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Sep 3 10:00:06 2013 New Revision: 202204 URL: http://gcc.gnu.org/viewcvs?rev=202204root=gccview=rev Log: 2013-09-03 Richard Biener rguent...@suse.de PR middle-end/57656 * fold-const.c (negate_expr_p): Fix division case. (negate_expr): Likewise. * gcc.dg/torture/pr57656.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57656.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/57656] [4.7/4.8 Regression] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57656 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Wrong |Wrong constant folding |constant folding --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org --- I think that tem = get_inner_reference (to, bitsize, bitpos, offset, mode1, unsignedp, volatilep, true); if (TREE_CODE (to) == COMPONENT_REF DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset); /* If we are going to use store_bit_field and extract_bit_field, make sure to_rtx will be safe for multiple use. */ mode = TYPE_MODE (TREE_TYPE (tem)); if (TREE_CODE (tem) == MEM_REF mode != BLKmode ((align = get_object_alignment (tem)) GET_MODE_ALIGNMENT (mode)) ((icode = optab_handler (movmisalign_optab, mode)) != CODE_FOR_nothing)) is overly pessimistic. What matters is the mode of the access, not that of the access base object! Which means the pre-handling of /* Handle misaligned stores. */ mode = TYPE_MODE (TREE_TYPE (to)); if ((TREE_CODE (to) == MEM_REF || TREE_CODE (to) == TARGET_MEM_REF) mode != BLKmode !mem_ref_refers_to_non_mem_p (to) should be made to trigger for all 'to', not just bare MEM_REF/TARGET_MEM_REF. Then the other movmisalign path can be completely removed.
[Bug libstdc++/58302] compilation error : std::negative_binomial_distribution::operator(e, p)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58302 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 3 10:12:19 2013 New Revision: 202208 URL: http://gcc.gnu.org/viewcvs?rev=202208root=gccview=rev Log: 2013-09-03 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/58302 * include/bits/random.tcc (negative_binomial_distribution:: operator()(_UniformRandomNumberGenerator, const param_type): Fix typo in template argument. * testsuite/26_numerics/random/negative_binomial_distribution/ operators/58302.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/58302.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/58302] compilation error : std::negative_binomial_distribution::operator(e, p)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58302 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 3 10:12:44 2013 New Revision: 202209 URL: http://gcc.gnu.org/viewcvs?rev=202209root=gccview=rev Log: 2013-09-03 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/58302 * include/bits/random.tcc (negative_binomial_distribution:: operator()(_UniformRandomNumberGenerator, const param_type): Fix typo in template argument. * testsuite/26_numerics/random/negative_binomial_distribution/ operators/58302.cc: New. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/58302.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/random.tcc
[Bug lto/58301] [4.9 Regression] error: inlining failed in call to always_inline 'set_mem_alias_set'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58301 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Honza said he fixed this.
[Bug libstdc++/58302] compilation error : std::negative_binomial_distribution::operator(e, p)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58302 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 3 10:19:16 2013 New Revision: 202210 URL: http://gcc.gnu.org/viewcvs?rev=202210root=gccview=rev Log: 2013-09-03 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/58302 * include/bits/random.tcc (negative_binomial_distribution:: operator()(_UniformRandomNumberGenerator, const param_type): Fix typo in template argument. * testsuite/26_numerics/random/negative_binomial_distribution/ operators/58302.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/58302.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.tcc
[Bug libstdc++/58302] compilation error : std::negative_binomial_distribution::operator(e, p)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58302 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.4 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0/4.8.2/4.7.4.
[Bug c++/58282] g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||EH, ice-on-valid-code, ||patch, trans-mem --- Comment #5 from vries at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00119.html
[Bug sanitizer/56535] ICE: in build2_stat, at tree.c:3885 when compiling with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56535 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- This has been fixed between r199406 (ICE) and r199412 (OK). r199409 seems the most likely candidate. If nobody care to understand why, I'll close this PR as fixed in the coming week.
[Bug libstdc++/58304] New: gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304
Bug ID: 58304
Summary: gcc dev branch compilation Failed at libstdc++-v3
(used gcc 4.7.3 to compile)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: harsha.patankar at gmail dot com
gcc dev branch compilation failed at libstdc++-v3.
/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:322:21:
internal compiler error: tree check: expected lambda_expr, have trait_expr in
cp_parser_lambda_expression, at cp/parser.c:8520
_M_cond.wait(__lock, [] { return _M_ready(); });
I'm using gcc 4.7.3 to compile
Version Details:
---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)
Error Details:
mkdir -p ./x86_64-unknown-linux-gnu/bits/stdc++.h.gch
/exports/src/gcc_build/./gcc/xgcc -shared-libgcc -B/exports/src/gcc_build/./gcc
-nostdinc++ -L/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include-x c++-header -nostdinc++ -g
-O2 -D_GNU_SOURCE
-I/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/exports/src/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/exports/src/gcc/libstdc++-v3/include/precompiled/stdc++.h \
-o x86_64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/exports/src/gcc/libstdc++-v3/include/precompiled/stdc++.h:103:0:
/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/include/future: In
member function ‘std::__future_base::_Result_base
std::__future_base::_State_base::wait()’:
/exports/src/gcc_build/x86_64-unknown-linux-gnu/libstdc++-v3/include/future:322:21:
internal compiler error: tree check: expected lambda_expr, have trait_expr in
cp_parser_lambda_expression, at cp/parser.c:8520
_M_cond.wait(__lock, [] { return _M_ready(); });
^
0xfbaef2 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/exports/src/gcc/gcc/tree.c:9207
0x5983db tree_check(tree_node*, char const*, int, char const*, tree_code)
/exports/src/gcc/gcc/tree.h:2600
0x6e6f97 cp_parser_lambda_expression
/exports/src/gcc/gcc/cp/parser.c:8520
0x6dfb3d cp_parser_primary_expression
/exports/src/gcc/gcc/cp/parser.c:4221
0x6e29ed cp_parser_postfix_expression
/exports/src/gcc/gcc/cp/parser.c:5804
0x6e4e67 cp_parser_unary_expression
/exports/src/gcc/gcc/cp/parser.c:7000
0x6e5a68 cp_parser_cast_expression
/exports/src/gcc/gcc/cp/parser.c:7592
0x6e5ad9 cp_parser_binary_expression
/exports/src/gcc/gcc/cp/parser.c:7692
0x6e62a6 cp_parser_assignment_expression
/exports/src/gcc/gcc/cp/parser.c:7928
0x6e6410 cp_parser_assignment_expression
/exports/src/gcc/gcc/cp/parser.c:7978
0x6e418e cp_parser_parenthesized_expression_list
/exports/src/gcc/gcc/cp/parser.c:6518
0x6e2c12 cp_parser_postfix_expression
/exports/src/gcc/gcc/cp/parser.c:5873
0x6e4e67 cp_parser_unary_expression
/exports/src/gcc/gcc/cp/parser.c:7000
0x6e5a68 cp_parser_cast_expression
/exports/src/gcc/gcc/cp/parser.c:7592
0x6e5ad9 cp_parser_binary_expression
/exports/src/gcc/gcc/cp/parser.c:7692
0x6e62a6 cp_parser_assignment_expression
/exports/src/gcc/gcc/cp/parser.c:7928
0x6e6513 cp_parser_expression
/exports/src/gcc/gcc/cp/parser.c:8090
0x6e6723 cp_parser_expression
/exports/src/gcc/gcc/cp/parser.c:8129
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #26 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #25)
I think that
tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,
unsignedp, volatilep, true);
if (TREE_CODE (to) == COMPONENT_REF
DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (bitregion_start, bitregion_end, to, bitpos,
offset);
/* If we are going to use store_bit_field and extract_bit_field,
make sure to_rtx will be safe for multiple use. */
mode = TYPE_MODE (TREE_TYPE (tem));
if (TREE_CODE (tem) == MEM_REF
mode != BLKmode
((align = get_object_alignment (tem))
GET_MODE_ALIGNMENT (mode))
((icode = optab_handler (movmisalign_optab, mode))
!= CODE_FOR_nothing))
is overly pessimistic. What matters is the mode of the access, not that
of the access base object!
Which means the pre-handling of
/* Handle misaligned stores. */
mode = TYPE_MODE (TREE_TYPE (to));
if ((TREE_CODE (to) == MEM_REF
|| TREE_CODE (to) == TARGET_MEM_REF)
mode != BLKmode
!mem_ref_refers_to_non_mem_p (to)
should be made to trigger for all 'to', not just bare MEM_REF/TARGET_MEM_REF.
Then the other movmisalign path can be completely removed.
struct s
{
int x:19;
} __attribute__((packed));
int foo(struct s *s)
{
s-x=1;
}
in this case of a packed field the TREE_CODE (to) will be COMPONENT_REF
TYPE_MODE (TREE_TYPE (to)) will be SImode.
If this would go to the pre-handling, this will not work for packed bit-fields.
this handling is just for: int *x;
*x = 1;
or: struct s *x, *y;
*x = *y; //if struct s is not BLKmode.
[Bug c++/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- If the compiler crashes it's a bug in the compiler, not libstdc++. Please provide the configure command used.
[Bug c++/58305] New: Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305
Bug ID: 58305
Summary: Deprecation warning for class not raised when not
assigning to a variable
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: languitar at semipol dot de
Deprecation warnings for classes do not work in case the class is used but not
assigned to a variable. The following code snippet illustrates the error:
class ToBeDeprecated {
} __attribute__ ((deprecated (deprecated!)));
ToBeDeprecated()
Despite using the class, no deprecation warning is shown. If I change the use
to
ToBeDeprecated x;
a warning is shown.
[Bug c++/58306] New: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 Bug ID: 58306 Summary: error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t.artem at mailcity dot com Created attachment 30744 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30744action=edit Sources + profile info blake2s.cpp: In function ‘void blake2s_update(blake2s_state*, const byte*, size_t)’: blake2s.cpp:133:40: error: corrupted value profile: value profile counter (11354724 out of 11329053) inconsistent with basic-block count (9600416) blake2s.cpp:157:49: error: corrupted value profile: value profile counter (11204032 out of 11277067) inconsistent with basic-block count (10940610) make: *** [blake2s.o] Error 1 make: *** Waiting for unfinished jobs CPU: Intel Core i5 2500 GCC: 4.7.3 ARC: i686 Makefile is included (just run make to see the error).
[Bug tree-optimization/58010] [4.8 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Sep 3 12:14:58 2013 New Revision: 202215 URL: http://gcc.gnu.org/viewcvs?rev=202215root=gccview=rev Log: 2013-09-03 Richard Biener rguent...@suse.de Backport from mainline 2013-08-30 Richard Biener rguent...@suse.de PR tree-optimization/58010 * tree-vect-loop.c (vect_create_epilog_for_reduction): Remove assert that we have a loop-closed PHI. * gcc.dg/pr58010.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr58010.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-loop.c
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-03 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Please provide a self-contained reproducer, what you provided doesn't compile at all.
[Bug tree-optimization/58228] [4.7/4.8 Regression] wrong code (with vectorization?) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58228 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Sep 3 12:16:28 2013 New Revision: 202216 URL: http://gcc.gnu.org/viewcvs?rev=202216root=gccview=rev Log: 2013-09-03 Richard Biener rguent...@suse.de Backport from mainline 2013-08-30 Richard Biener rguent...@suse.de PR tree-optimization/58228 * tree-vect-data-refs.c (vect_analyze_data_ref_access): Do not allow invariant loads in nested loop vectorization. * gcc.dg/torture/pr58228.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58228.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-vect-data-refs.c
[Bug c++/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|major |normal --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Doesn't look like a C++ front-end issue.
[Bug tree-optimization/58246] [4.7/4.8 Regression] wrong code at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58246 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Sep 3 12:18:34 2013 New Revision: 202217 URL: http://gcc.gnu.org/viewcvs?rev=202217root=gccview=rev Log: 2013-09-03 Richard Biener rguent...@suse.de Backport from mainline 2013-08-29 Richard Biener rguent...@suse.de PR tree-optimization/58246 * tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1): Properly handle the dominance check inside a basic-block. * gcc.dg/torture/pr58246.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr58246.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-dce.c
[Bug tree-optimization/58010] [4.8 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305
--- Comment #2 from Johannes Wienke languitar at semipol dot de ---
class ToBeDeprecated {
} __attribute__ ((deprecated (deprecated!)));
int main() {
ToBeDeprecated();
ToBeDeprecated x;
return 0;
}
The first use does not issue the warning, the second does.
[Bug c++/58076] internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_narrower, at tree.c:8500
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58076 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Feedback not forthcoming.
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW
[Bug fortran/58307] New: Bogus error 'Function requires an argument list'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58307 Bug ID: 58307 Summary: Bogus error 'Function requires an argument list' Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Reported by Jan Wittke at https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/93BFKizfmEM ... The following (invalid) code: implicit none type point real:: x,y,z end type real(point) :: this end produces (with 4.7, 4.8 and trunk) the error message real(point) :: this 1 Error: Function 'point' requires an argument list at (1) which is misleading, since 'point' is obviously not a function. 4.3 gives: real(point) :: this 1 Error: Syntax error in structure constructor at (1) which is not much better, since no structure constructor is involved here, either.
[Bug c++/58306] error: corrupted value profile: value profile counter (X out of Y) inconsistent with basic-block count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306 --- Comment #2 from Artem S. Tashkinov t.artem at mailcity dot com --- (In reply to Paolo Carlini from comment #1) Doesn't look like a C++ front-end issue. Surely, but I had to choose something not knowing what to choose.
[Bug c++/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-03 Ever confirmed|0 |1 Severity|major |normal --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Also provide the exact Revision you are trying to build (I use 4.7.x all the time to build mainline (today too, multiple times, r202217 moments ago) and I have never seen this ICE.
[Bug fortran/33906] -fshape-check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33906 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- *** Bug 50548 has been marked as a duplicate of this bug. ***
[Bug fortran/50548] gfortran -fcheck=all run time would be nice to detect different shapes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50548 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org --- Dup of 33906. *** This bug has been marked as a duplicate of bug 33906 ***
[Bug fortran/58307] Bogus error 'Function requires an argument list'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58307 --- Comment #1 from janus at gcc dot gnu.org --- (In reply to janus from comment #0) produces (with 4.7, 4.8 and trunk) the error message real(point) :: this 1 Error: Function 'point' requires an argument list at (1) This error message comes from gfc_match_rvalue in primary.c. For some reason, the 'point' symbol has attr.function and attr.generic set and attr.flavor == FL_PROCEDURE. Maybe the problem was introduced with the implementation of 'constructors' in 4.7?
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 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 #3 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, this seems easy to fix.
[Bug fortran/58307] Bogus error 'Function requires an argument list'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58307 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- 4.6.4 gives Error: Syntax error in structure constructor at (1) and 4.7.3 Error: Function 'point' requires an argument list at (1) Would you expect an error of the kind Error: Parameter 'point' at (1) has not been declared or is a variable, which does not reduce to a constant expression ?
[Bug fortran/58307] Bogus error 'Function requires an argument list'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58307 --- Comment #3 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) 4.6.4 gives Error: Syntax error in structure constructor at (1) and 4.7.3 Error: Function 'point' requires an argument list at (1) Ok, so the new error message is sort of a regression in 4.7. But since the old one was not fully correct either, I wouldn't count it as a real regression. Would you expect an error of the kind Error: Parameter 'point' at (1) has not been declared or is a variable, which does not reduce to a constant expression ? Well, sounds a bit better at least (although 'point' is not a parameter).
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #193 from Jan Hubicka hubicka at gcc dot gnu.org --- I am building firefox with -O3 and get no undefined symbols. Can you, please, relink with -Wl,--no-demangle --save-temps -fdump-ipa-all and try to look up the missing symbol in -lm.res file and if it not UNDEF there make somewhere available the dumps? If it is undefined there, it may be firefox bug..
[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54072 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at revision 202213. Note that for IAND, IOR, ..., the constraint is a 'shall', i.e., according my understanding of the standard, the burden is on the user not on the compiler.
[Bug fortran/55735] ICE with deferred-length strings in COMMON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55735 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Ever confirmed|0 |1
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #4 from Matthias Klose doko at gcc dot gnu.org --- Mark's patch is in binutils 2.23.x, but the testcase is still failing on x86_64 linux.
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #4 from Matthias Klose doko at gcc dot gnu.org --- Mark's patch is in binutils 2.23.x, but the testcase is still failing on x86_64 linux. Right, same problem with binutils 2.23.1 addr2line on Solaris. Rainer
[Bug fortran/58204] Spurious error when using BOZ literal to set an integer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58204 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 CC||burnus at gcc dot gnu.org, ||sgk at troutmask dot apl.washingto ||n.edu Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- After knotting my neurons over the f2008 standard and their extracts in this PR and PR54072, I think the current implementation (r202213) is valid for f95, but does not handle the way it should be interpreted for more recent standards, at least for f2008 (did not checked f2003). Concerning the sign bit, i.e., The interpretation of a bit sequence whose most significant bit is 1 is processor dependent., I think it does not make sense to reject it (does anyone knows a present piece of hardware which is not using two's complement?).
[Bug fortran/57616] Support -fsanitize=undefined in Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57616 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Ever confirmed|0 |1
[Bug fortran/57822] I/O: (g0) wrongly prints E+0000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57822 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Ever confirmed|0 |1
[Bug c++/51629] Default Destructor and template extern Instantiation cause the Destructor to be missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51629 rob.desbois at gmail dot com changed: What|Removed |Added CC||rob.desbois at gmail dot com --- Comment #2 from rob.desbois at gmail dot com --- I believe I have incurred this same bug on gcc 4.7.2 with copy constructor, and both move copy assignment operators. A workaround for my case is to have only the function declaration inline, and to move the defaulted declaration out of line. Keeping everything else the same - extern template declaration, explicit template instantiation, and file layout - this yields the required results.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #194 from Markus Trippelsdorf markus at trippelsdorf dot de --- (In reply to Jan Hubicka from comment #193) I am building firefox with -O3 and get no undefined symbols. Can you, please, relink with -Wl,--no-demangle --save-temps -fdump-ipa-all and try to look up the missing symbol in -lm.res file and if it not UNDEF there make somewhere available the dumps? If it is undefined there, it may be firefox bug.. Hmm, it's strange, because there are five undefined references; one of them does not appear in lm.res at all and the other four are all PREVAILING_DEF_IRONLY. (The whole dump is huge. Please tell me which part you need and I will try to upload it somewhere.)
[Bug c++/58308] Segmentation fault: internal compiler error: in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58308 --- Comment #1 from Dmitry dmitriy-hshg at mail dot ru --- c++11 mode is used
[Bug c/58309] New: spurious parameter set but not used warning in cilk plus array code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58309
Bug ID: 58309
Summary: spurious parameter set but not used warning in cilk
plus array code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kuszmaul at gmail dot com
The following program produces a spurious warning when using cilk plus array
notation.
$ cat foo.c
void scale(double *A, int n, double x) {
A[0:n] *= x;
}
$ gcc foo.c -W -Wall -g -c -fcilkplus
foo.c: In function ‘scale’:
foo.c:1:27: warning: parameter ‘n’ set but not used
[-Wunused-but-set-parameter]
void scale(double *A, int n, double x) {
^
$ gcc --version
gcc (GCC) 4.8.0 20120912 (experimental)
Copyright (C) 2012 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++/58308] New: Segmentation fault: internal compiler error: in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58308
Bug ID: 58308
Summary: Segmentation fault: internal compiler error: in
make_decl_rtl, at varasm.c:1147
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dmitriy-hshg at mail dot ru
Next code causes GCC 4.7.3 to fail, it should report problem.
int main()
{
int x = 666;
struct A {
int *p = x;
} a;
}
Thank you.
[Bug fortran/58310] New: Allocatable component arrays: Wrong code after calling a subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58310 Bug ID: 58310 Summary: Allocatable component arrays: Wrong code after calling a subroutine Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: pault at gcc dot gnu.org As reported by James Spencer at https://groups.google.com/forum/#!topic/comp.lang.fortran/VuFvOsLs6hE The call to the subroutine causes copy-in/copy-out - and that somehow causes that that access to invalid memory. (Side remark: I think the copy-in/copy-out is required as we do not have byte strides, just element-based strides. See http://gcc.gnu.org/wiki/ArrayDescriptorUpdate) Output of the code below: 1 1 2 2 in s1:1 1 in s1:2 2 0 0 21884992 0 Program received signal SIGABRT: Process abort signal. When run under valgrind, the output is correct - but one gets two errors: Once directly after the subroutine call: ==21383== Invalid read of size 4 ==21383==at 0x4F15AB0: extract_int (write.c:440) ==21383==by 0x4F17020: write_integer (write.c:1250) And at the very end: ==21383== Invalid free() / delete / delete[] / realloc() Here is the code which causes the problems with GCC 4.3 to GCC 4.9: program p implicit none type x_t integer, allocatable :: v(:) end type x_t type y_t type(x_t) :: x end type y_t type(y_t), allocatable, target :: y(:) integer :: i integer, parameter :: N=2 allocate(y(N)) do i = 1,N allocate(y(i)%x%v(N)) y(i)%x%v = i end do do i = 1,N write (6,*) y(i)%x%v end do call s1(y%x) do i = 1,N write (6,*) y(i)%x%v end do deallocate(y) contains subroutine s1(x) type(x_t), intent(inout) :: x(:) integer :: i do i = 1, size(x) print *, 'in s1: ', x(i)%v end do end subroutine s1 end program p
[Bug fortran/58310] Allocatable component arrays: Wrong code after calling a subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58310 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- As James had already pointed out - and as Richard Maine confirmed in a follow up, the code violates the following constraint of Fortran 2003: C614 (R612) There shall not be more than one part-ref with nonzero rank. A part-name to the right of a part-ref with nonzero rank shall not have the ALLOCATABLE or POINTER attribute. However, gfortran does not diagnose it. (Nor do PGI, crayftn or ifort; I cannot test NAG f95 at the moment.) The other mentioned compiler handle it - probably due to avoidance of copy-in/out. See also follow up in thread and the old posting, linked in the original reporter's email.
[Bug c++/58308] Segmentation fault: internal compiler error: in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58308 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.0 Resolution|--- |FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Mainline (would be 4.9.0) is fine.
[Bug fortran/58307] Bogus error 'Function requires an argument list'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58307 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 #0) produces (with 4.7, 4.8 and trunk) the error message real(point) :: this 1 Error: Function 'point' requires an argument list at (1) which is misleading, since 'point' is obviously not a function. Well, in this case it isn't. However, it is permitted to have a function with the same generic name as a derived type (constructors). That wouldn't help in this case as one needs a constant/initialization expression, but it explains the error message. (Internally, gfortran generates a generic function symbol under the derived-type name - and links the hidden symbol with the derived type to it.) As always, providing a good error message in all cases is difficult - the other error message is also not that friendly as earlier gfortrans show. pathf95/crayftn have: This use of derived type POINT is not valid. g95 has: Error: Syntax error in structure constructor at (1) pgf95 has: PGF90-S-0087-Non-constant expression where constant expression required PGF90-S-0081-Illegal selector - KIND parameter has unknown value for data type ifort has: A kind type parameter must be a compile-time constant.
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Unfortunately not trivial to do, because, per the general rules about deprecated types, given: typedef ToBeDeprecated NotToBeDeprecated; we do *not* warn to warn for either: NotToBeDeprecated(); NotToBeDeprecated y; Anyway, not a regression, icc behaves like gcc, etc: the issue has to wait a bit.
[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Summary|ice in |[4.9 Regression] ice in |gimple_get_virt_method_for_ |gimple_get_virt_method_for_ |binfo with -O2 |binfo with -O2 Ever confirmed|0 |1
[Bug tree-optimization/58311] New: [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58311 Bug ID: 58311 Summary: [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 30745 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30745action=edit reduced testcase Compiler output: $ gcc -fdevirtualize testcase.C testcase.C:14:1: internal compiler error: Segmentation fault } ^ 0xc1423f crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:335 0xa47b91 hash_tableodr_hasher, xcallocator::find_slot_with_hash(tree_node const*, unsigned int, insert_option) /mnt/svn/gcc-trunk/gcc/hash-table.h:774 0xa463ad get_odr_type(tree_node*, bool) /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:251 0xa46cb4 possible_polymorphic_call_targets(tree_node*, long, bool*, void**) /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:596 0xa47263 possible_polymorphic_call_targets /mnt/svn/gcc-trunk/gcc/ipa-utils.h:87 0xa47263 ipa_devirt /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:790 0xa47263 execute /mnt/svn/gcc-trunk/gcc/ipa-devirt.c:985 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. ==7675== Invalid read of size 8 ==7675==at 0xA47B91: hash_tableodr_hasher, xcallocator::find_slot_with_hash(tree_node const*, unsigned int, insert_option) (hash-table.h:774) ==7675==by 0xA463AD: get_odr_type(tree_node*, bool) (ipa-devirt.c:251) ==7675==by 0xA46CB4: possible_polymorphic_call_targets(tree_node*, long, bool*, void**) (ipa-devirt.c:596) ==7675==by 0xA47263: (anonymous namespace)::pass_ipa_devirt::execute() (ipa-utils.h:87) ==7675==by 0xB22AA9: execute_one_pass(opt_pass*) (passes.c:2201) ==7675==by 0xB2327A: execute_ipa_pass_list(opt_pass*) (passes.c:2565) ==7675==by 0x88F575: compile() (cgraphunit.c:1965) ==7675==by 0x88FD09: finalize_compilation_unit() (cgraphunit.c:2209) ==7675==by 0x693630: cp_write_global_declarations() (decl2.c:4364) ==7675==by 0xC142AC: compile_file() (toplev.c:560) ==7675==by 0xC160C9: toplev_main(int, char**) (toplev.c:1878) ==7675==by 0x5A3C60C: (below main) (in /lib64/libc-2.15.so) ==7675== Address 0x8 is not stack'd, malloc'd or (recently) free'd ==7675== testcase.C:14:1: internal compiler error: Segmentation fault $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-202196-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-202196-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.9.0 20130903 (experimental) (GCC)
[Bug fortran/58310] Allocatable component arrays: Wrong code after calling a subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58310 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Following the links it seems that the use of y%x is invalid. So this PR is more a bout a missing diagnostic rather than a wrong code. Note that g95 gives the same output as ifort.
[Bug bootstrap/53902] make install fails on SunOS 5.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 rogerio.araujo at gmail dot com changed: What|Removed |Added CC||rogerio.araujo at gmail dot com --- Comment #5 from rogerio.araujo at gmail dot com --- Same build error occured while building gcc 4.8.0 on Solaris 10.
[Bug other/58312] libssp configure check for usable vsnprintf is broken on cross-compilers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- If your target uses glibc, you don't need libssp anyway. libssp is used by LINK_SSP_SPEC if TARGET_LIBC_PROVIDES_SSP is not defined. TARGET_LIBC_PROVIDES_SSP is defined when glibc headers are available when configuring GCC, and they are version 2.4 or later (or some other conditions for some other C libraries). The checks for headers do cause problems when bootstrapping a cross toolchain - you may need to set gcc_cv_libc_provides_ssp=yes to get a correctly configured bootstrap compiler that can build glibc. See http://gcc.gnu.org/ml/gcc/2013-06/msg00112.html for how I think that should be fixed - a configure option to specify the target glibc version. If your target does not use glibc, I have no advice beyond the general principle that the default should be assuming a function works and then known-broken systems (if any are supported) can be blacklisted.
[Bug other/58312] libssp configure check for usable vsnprintf is broken on cross-compilers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #3 from Brooks Moses brooks at gcc dot gnu.org --- Thanks, Joseph. This is a straightforward Linux target using glibc, so I'll investigate to see why the binary in question is relying on libssp rather than glibc.
[Bug c++/58300] ICE: in decide_is_symbol_needed, at cgraphunit.c:233 with -fvtable-verify=preinit on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58300 --- Comment #4 from Caroline Tice cmtice at google dot com --- I am looking into this now. I will update this bug when I know more.
[Bug other/58312] libssp configure check for usable vsnprintf is broken on cross-compilers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #1 from Brooks Moses brooks at gcc dot gnu.org --- Jakub, I added you to the cc list in hopes that you may be able to comment on the original reasoning for this being a runtime check rather than simply a check for the ability to link a program calling vsnprintf, since you were the original author.
[Bug fortran/58310] Allocatable component arrays: Wrong code after calling a subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58310 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords|accepts-invalid, diagnostic |wrong-code Summary|Missing diagnosis for C614: |Allocatable component |[…] A part-name to the |arrays: Wrong code after |right of a part-ref with|calling a subroutine |nonzero rank shall not have | |the ALLOCATABLE or POINTER | |attribute. | --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Sigh, seemingly, this code does *not* violate C614 - and should be supported. (See thread.) y%x%v would be bad, but y%x isn't. In this special case, not even copy-in should be need as the sizes and padding should allow for element-size strides. Otherwise the new descriptor is required for to avoid it in the general case. Still, a wrong-code issue is a wrong-code issue…
[Bug other/58312] New: libssp configure check for usable vsnprintf is broken on cross-compilers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 Bug ID: 58312 Summary: libssp configure check for usable vsnprintf is broken on cross-compilers. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: brooks at gcc dot gnu.org The libssp configure script contains a check for whether vsnprintf is usable, starting around line 128. This check is based on an AC_RUN_IFELSE call, which compiles and runs a program that uses a vsnprintf call. The problem is in the fallback argument for the cross-compiling case, which is simply ssp_have_usable_vsnprintf=undef -- which is to say, assume it does not work. The result is that about a third of the libssp files -- sprintf-chk.c, snprintf-chk.c, vsprintf-chk.c, and vsnprintf-chk.c -- are then effectively #ifdef'ed out of existence. This is a significant problem; we have programs compiled with a native compiler that are having runtime link errors with the runtime libraries from a cross compiler for the same target, because functions such as __sprintf_chk are not defined in the cross-compiled libssp.so. It's not at all clear to me why this check needs to be a runtime check at all; is it not simply sufficient to check for the existence of a vsnprintf function? There are no comments in the code to indicate why this is insufficient, and the runtime check was present in the initial version of the code without comments: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00066.html
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 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 Target Milestone|--- |4.9.0
[Bug c++/24926] gcc ignores access level violation for anonymous structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug middle-end/58096] [4.9 Regression] gcc.dg/tree-ssa/attr-alias.c fails with r201439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org --- This is fixed for cris-elf in (201978:202144] apparently r202111 as also obvious from the message at gcc-patches. It's probably fixed everywhere. Can Pat the reporter or Jan the fixer please verify and close if so?
[Bug other/58312] libssp configure check for usable vsnprintf is broken on cross-compilers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #4 from Brooks Moses brooks at gcc dot gnu.org --- It turns out that we do need these symbols in libssp despite having a nice plain x86-Linux environment. We've got some precompiled blobs from who-knows-where that want the LIBSSP_1.0 version of the __vsnprintf_chk symbol -- and, although our glibc exports __vsnprintf_chk, it of course exports it with a GLIBC_2.3.4 version. Failure ensues. So, for consistency for things that either explicitly declare -lssp or otherwise end up with the LIBSSP symbol versions, I think it's nonetheless useful to fix the libssp configure file for cross-compilation. Thus, patch posted: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00174.html
[Bug fortran/58204] [F2008] BOZ literals in the int function should not be treated as unsigned integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58204 Sean Santos quantheory at gmail dot com changed: What|Removed |Added Summary|Spurious error when using |[F2008] BOZ literals in the |BOZ literal to set an |int function should not be |integer |treated as unsigned ||integers --- Comment #2 from Sean Santos quantheory at gmail dot com --- Yes, re-reading the Fortran 95 standard, it does look like what gfortran is doing follows the standard for a BOZ in a DATA statement, but BOZ is not allowed in an int, so Fortran 95 isn't relevant for the particular test program in comment 0. In the Fortran 2008 standard, it seems like this is still a bug, for the reasons I mentioned. Fortran 2003 is weird. If the BOZ is in the int function, it is supposed to be treated as an integer constant, much like in a Fortran 95 data statement. If the BOZ is in a real function, it is treated as a bit pattern, just like in Fortran 2008. So actually, you could argue that gfortran is OK for Fortran 2003 as well. I'm marking this as Fortran 2008, accordingly. My main motivation for raising this issue at all is that this is one of several reasons that you have to really jump through hoops to set a real to IEEE infinity or NaN. In fact, this seems to be the simplest way to create a constant for double-precision -Infinity without using -fno-range-check: integer(8), parameter :: ninf_bits = ibset(int(Z'7FF0',8),bit_size(1_8)-1) real(8), parameter :: neginf = transfer(ninf_bits,1._8) It's not the worst thing ever, but it's more than a little silly.
[Bug fortran/58204] [F2008] BOZ literals in the int function should not be treated as unsigned integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58204 kargl at gcc dot gnu.org changed: What|Removed |Added CC|sgk at troutmask dot apl.washingto | |n.edu | --- Comment #3 from kargl at gcc dot gnu.org --- Remove myself from cc list. I don't have time to work on gfortran in the forseeable future.
