[Bug target/68355] Constant byte is passed on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68355 --- Comment #2 from H.J. Lu --- clang doesn't pass constant byte at all: [hjl@gnu-tools-1 pr67239]$ /export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -S -O2 foo.ii -std=c++11 [hjl@gnu-tools-1 pr67239]$ cat foo.s .text .file "foo.ii" .globl _Z3yyyv .align 16, 0x90 .type _Z3yyyv,@function _Z3yyyv:# @_Z3yyyv .cfi_startproc # BB#0: jmp _Z3xxx17integral_constantIbLb1EE # TAILCALL .Lfunc_end0: .size _Z3yyyv, .Lfunc_end0-_Z3yyyv .cfi_endproc
[Bug bootstrap/68346] [6 Regression] Bootstrap failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68346 Andreas Schwab changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #4 from Andreas Schwab --- Still fails on aarch64 as of r230393. ../../gcc/builtins.c:1101:46: error: self-comparison always evaluates to false [-Werror=tautological-compare] if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM ^~
[Bug tree-optimization/68356] New: FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 Bug ID: 68356 Summary: FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: fxcoudert at gcc dot gnu.org, howarth.at.gcc.testresults at gmail dot com, iains at gcc dot gnu.org, rsandifo at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin1* Target: x86_64-apple-darwin1* Build: x86_64-apple-darwin1* The test gcc.dg/torture/pr68264.c introduced at revision r230323 fails on x86_64-apple-darwin1(0|4) FAIL: gcc.dg/torture/pr68264.c -O0 execution test FAIL: gcc.dg/torture/pr68264.c -O1 execution test FAIL: gcc.dg/torture/pr68264.c -O2 execution test FAIL: gcc.dg/torture/pr68264.c -O2 -flto execution test FAIL: gcc.dg/torture/pr68264.c -O2 -flto -flto-partition=none execution test FAIL: gcc.dg/torture/pr68264.c -O3 -g execution test FAIL: gcc.dg/torture/pr68264.c -Os execution test The test fails at run time with all the revisions I have tested (from 4.8 up to trunk and also with clang). Could it be another manifestation of pr62018?
[Bug c++/68357] New: [6 Regression] FAIL: g++.dg/other/darwin-cfstring1.C -std=* (internal compiler error) on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68357
Bug ID: 68357
Summary: [6 Regression] FAIL: g++.dg/other/darwin-cfstring1.C
-std=* (internal compiler error) on
x86_64-apple-darwin1(0|4)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: fxcoudert at gcc dot gnu.org,
howarth.at.gcc.testresults at gmail dot com,
iains at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-apple-darwin1*
Target: x86_64-apple-darwin1*
Build: x86_64-apple-darwin1*
At revision r230384, compiling the test g++.dg/other/darwin-cfstring1.C gives
the ICE
[Book15] f90/bug% g++6
/opt/gcc/_clean/gcc/testsuite/g++.dg/other/darwin-cfstring1.C -std=gnu++98
-ftrack-macro-expansion=0 -mconstant-cfstrings
/opt/gcc/_clean/gcc/testsuite/g++.dg/other/darwin-cfstring1.C: In function 'int
main()':
/opt/gcc/_clean/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:21:20: error:
CFString literal expression is not a string constant
CFStringRef s2 = CFSTR(cond? "Str2": "Str3"); /* { dg-error "CFString
literal expression is not a string constant" } */
^
/opt/gcc/_clean/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:22:20: error:
CFString literal expression is not a string constant
CFStringRef s3 = CFSTR(func()); /* { dg-error "CFString literal expression
is not a string constant" } */
^
/opt/gcc/_clean/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:21:20: internal
compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in useless_type_conversion_p, at gimple-expr.c:83
CFStringRef s2 = CFSTR(cond? "Str2": "Str3"); /* { dg-error "CFString
literal expression is not a string constant" } */
^
/opt/gcc/_clean/gcc/testsuite/g++.dg/other/darwin-cfstring1.C:21:20: internal
compiler error: Abort trap: 6
Revision r230359 is OK.
[Bug libstdc++/68353] [6 Regression] libstdc++-v3/include/bits/basic_string. h:5524:31: error: 'wcstoll' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68353 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonathan Wakely --- Should be fixed at r230395
[Bug libstdc++/68353] [6 Regression] libstdc++-v3/include/bits/basic_string. h:5524:31: error: 'wcstoll' is not a member of 'std'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68353 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Sun Nov 15 11:15:08 2015 New Revision: 230395 URL: https://gcc.gnu.org/viewcvs?rev=230395&root=gcc&view=rev Log: PR libstdc++/68353 fix _GLIBCXX_USE_C99_WCHAR test PR libstdc++/68353 * include/bits/basic_string.h: Test value of _GLIBCXX_USE_C99_WCHAR not whether it is defined. * include/ext/vstring.h: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/ext/vstring.h
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 --- Comment #17 from H.J. Lu --- It is related to PR 68355. With -finline-small-functions, we call std::_Hashtable, std::__detail::_Identity, std::equal_to, std::hash, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits >::_M_rehash_aux(unsigned int, std::integral_constant) with movq%rdi, %rbx movq%rdx, %r14 subl$8, %esp pushq $0 .LEHB23: .cfi_escape 0x2e,0x10 call _ZNSt10_HashtableIiiN9__gnu_cxx21throw_allocator_limitIiEENSt8__detail9_IdentityESt8equal_toIiESt4hashIiENS3_18_Mod_range_hashingENS3_20_Default_ranged_hashENS3_20_Prime_rehash_policyENS3_17_Hashtable_traitsILb0ELb1ELb113_M_rehash_auxEjSt17integral_constantIbLb1EE .LEHE23: and we generate: _ZNSt10_HashtableIiiN9__gnu_cxx21throw_allocator_limitIiEENSt8__detail9_IdentityESt8equal_toIiESt4hashIiENS3_18_Mod_range_hashingENS3_20_Default_ranged_hashENS3_20_Prime_rehash_policyENS3_17_Hashtable_traitsILb0ELb1ELb113_M_rehash_auxEjSt17integral_constantIbLb1EE: .LFB9712: .cfi_startproc .cfi_personality 0x3,__gxx_personality_v0 .cfi_lsda 0x3,.LLSDA9712 pushq %r15 .cfi_def_cfa_offset 16 .cfi_offset 15, -16 pushq %r14 .cfi_def_cfa_offset 24 .cfi_offset 14, -24 pushq %r13 .cfi_def_cfa_offset 32 .cfi_offset 13, -32 pushq %r12 .cfi_def_cfa_offset 40 .cfi_offset 12, -40 pushq %rbp .cfi_def_cfa_offset 48 .cfi_offset 6, -48 pushq %rbx .cfi_def_cfa_offset 56 .cfi_offset 3, -56 subl$136, %esp .cfi_def_cfa_offset 192 movq%rdi, %r15 movl%esi, %r12d cmpl$1, %esi Change .cfi_escape 0x2e,0x10 to .cfi_escape 0x2e,0 fixes the crash. It seems that empty argument, like std::true_type, isn't handled properly.
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 H.J. Lu changed: What|Removed |Added Depends on||60336 --- Comment #18 from H.J. Lu --- I think it is wrong for C++ to pass empty argument on stack. It should be handled the same way as C. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 [Bug 60336] empty struct value is passed differently in C and C++
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #25 from H.J. Lu --- (In reply to Andrew Pinski from comment #23) > (In reply to H.J. Lu from comment #22) > > This is a target independent issue. Clang++ skips empty struct argument > > and g++ passes it. Skip empty struct argument requires middle-end changes. > > Except in c++, the struct is non zero in size. I think empty struct should be considered as zero size for argument passing, like clang does. This bug causes PR 67239.
[Bug fortran/68358] New: Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358
Bug ID: 68358
Summary: Some tests in gfortran.dg fail when compiled with '-g
-flto' and Xcode 7
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: fxcoudert at gcc dot gnu.org, hubicka at gcc dot gnu.org,
iains at gcc dot gnu.org, mliska at suse dot cz
Target Milestone: ---
Host: x86_64-apple-darwin14
Target: x86_64-apple-darwin14
Build: x86_64-apple-darwin14
The following tests fail when compiled with '-g -flto' and Xcode 7
FAIL: gfortran.dg/alloc_comp_deep_copy_1.f03 -g -flto (test for excess
errors)
FAIL: gfortran.dg/allocate_deferred_char_scalar_1.f03 -g -flto (test for
excess errors)
FAIL: gfortran.dg/allocate_with_source_8.f08 -g -flto (test for excess
errors)
FAIL: gfortran.dg/assumed_rank_2.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/class_48.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/class_optional_2.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/class_to_type_1.f03 -g -flto (test for excess errors)
FAIL: gfortran.dg/class_to_type_4.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/defined_assignment_2.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/finalize_12.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/finalize_15.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/inline_transpose_1.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/intrinsic_spread_1.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/maxlocval_4.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/minlocval_3.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/minlocval_4.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/minmaxloc_3.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/namelist_69.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/namelist_70.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/realloc_on_assign_17.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/typebound_operator_9.f03 -g -flto (test for excess errors)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03 -g -flto (test for excess
errors)
FAIL: gfortran.dg/vector_subscript_1.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/widechar_intrinsics_10.f90 -g -flto (test for excess
errors)
FAIL: gfortran.dg/widechar_intrinsics_5.f90 -g -flto (test for excess
errors)
FAIL: gfortran.dg/zero_sized_1.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -g -flto (test for excess errors)
FAIL: gfortran.dg/ieee/large_3.F90 -g -flto (test for excess errors)
plus with -m32 (not with -m64)
FAIL: gfortran.dg/achar_2.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/allocate_with_source_5.f90 -g -flto (test for excess
errors)
FAIL: gfortran.dg/maxlocval_2.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/minlocval_1.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/minmaxloc_1.f90 -g -flto (test for excess errors)
FAIL: gfortran.dg/ieee/ieee_1.F90 -g -flto (test for excess errors)
plus with -m64 (not with -m32)
FAIL: gfortran.dg/bound_7.f90 -g -flto (test for excess errors)
These failures are of the kind
warning: (i386) could not find object file symbol for symbol
___x86.get_pc_thunk.ax
for gfortran.dg/achar_2.f90, maxlocval_2.f90, minlocval_1.f90 or more complex
as in
[Book15] f90/bug% gfc
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90 -g -flto
-m32
warning: (i386) could not find object file symbol for symbol
___selectors_MOD___final_selectors_Selector_t
warning: (i386) could not find object file symbol for symbol
___selectors_MOD___copy_selectors_Selector_t
...
These failures appear with
[Book15] f90/bug% dsymutil -v
Apple LLVM 7.0.0 (clang-700.1.76)
but I don't see them with
@(#)PROGRAM:dsymutil PROJECT:dwarfutils-119
With the patch
--- ../_clean/gcc/testsuite/lib/prune.exp 2015-10-09 18:05:39.0
+0200
+++ gcc/testsuite/lib/prune.exp 2015-11-15 12:10:09.0 +0100
@@ -69,6 +69,9 @@ proc prune_gcc_output { text } {
# Ignore harmless warnings from Xcode 4.0.
regsub -all "(^|\n)\[^\n\]*ld: warning: could not create compact unwind
for\[^\n\]*" $text "" text
+
+# Ignore harmless warnings from Xcode 7.0.
+regsub -all "(^|\n)warning: \[^\n\]* could not find object file symbol for
symbol\[^\n\]*" $text "" text
# Call into multiline.exp to handle any multiline output directives.
set text [handle-multiline-outputs $text]
these failures are gone.
Before reporting upstream, I'ld like to be sure that the issue is not due to
gfortran and/or lto: as shown by PRs
[Bug c++/68357] [6 Regression] FAIL: g++.dg/other/darwin-cfstring1.C -std=* (internal compiler error) on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68357 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 Ever confirmed|0 |1
[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 Ever confirmed|0 |1
[Bug target/67973] All the tests for -gstabs* fail on x86_64-apple-darwin14 with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67973 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 Ever confirmed|0 |1
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 Ever confirmed|0 |1
[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 Ever confirmed|0 |1
[Bug testsuite/67958] The tests changed by r223498 now FAILs on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67958 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-15 Ever confirmed|0 |1
[Bug c++/68359] New: ice: tree check: expected integer_cst, have nop_expr in get_len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68359
Bug ID: 68359
Summary: ice: tree check: expected integer_cst, have nop_expr
in get_len
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at os dot inf.tu-dresden.de
Target Milestone: ---
With gcc version 6.0.0 20151115 (experimental) (GCC), x86_64:
$ cat t.i
struct G {};
struct L
{
enum class T { S } t;
G f() const
{
switch (t)
{
case T::S: return G();
}
}
};
$ g++ -c t.i
t.i: In member function ‘G L::f() const’:
t.i:10:15: internal compiler error: tree check: expected integer_cst, have
nop_expr in get_len, at tree.h:5167
case T::S: return G();
^
0xf534ec tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9587
0x8502b8 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3212
0x8502b8 wi::extended_tree<192>::get_len() const
../../gcc/gcc/tree.h:5167
0x8502b8 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/gcc/wide-int.h:898
0x8502b8
wide_int_ref_storage::wide_int_ref_storage
> >(generic_wide_int > const&, unsigned int)
../../gcc/gcc/wide-int.h:945
0x8502b8 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/gcc/wide-int.h:722
0x8502b8 int wi::cmps >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/gcc/wide-int.h:1900
0x8502b8 tree_int_cst_compare(tree_node const*, tree_node const*)
../../gcc/gcc/tree.h:5236
0x8502b8 c_add_case_label(unsigned int, splay_tree_s*, tree_node*, tree_node*,
tree_node*, tree_node*, bool*)
../../gcc/gcc/c-family/c-common.c:6633
0x5f07e3 finish_case_label(unsigned int, tree_node*, tree_node*)
../../gcc/gcc/cp/decl.c:3417
0x6fec62 cp_parser_label_for_labeled_statement
../../gcc/gcc/cp/parser.c:10259
0x711c00 cp_parser_statement
../../gcc/gcc/cp/parser.c:10132
0x712fc1 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10456
0x7130c3 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10410
0x71a8fd cp_parser_implicitly_scoped_statement
../../gcc/gcc/cp/parser.c:11550
0x712404 cp_parser_selection_statement
../../gcc/gcc/cp/parser.c:10632
0x712404 cp_parser_statement
../../gcc/gcc/cp/parser.c:10040
0x712fc1 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10456
0x7130c3 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10410
0x713250 cp_parser_function_body
../../gcc/gcc/cp/parser.c:20225
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.
The ICE goes away when removing the 'const'.
The code works/compiles with gcc <= 5 and with gcc6 about a week old.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #24 from Markus Trippelsdorf --- Forgot to mention: ggc_collect happens during pass_reload.
[Bug fortran/63932] posible problem with allocatable character(:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63932 --- Comment #3 from Paul Thomas --- Author: pault Date: Sun Nov 15 14:07:52 2015 New Revision: 230396 URL: https://gcc.gnu.org/viewcvs?rev=230396&root=gcc&view=rev Log: 2015-11-15 Paul Thomas PR fortran/50221 PR fortran/68216 PR fortran/63932 PR fortran/66408 * trans_array.c (gfc_conv_scalarized_array_ref): Pass the symbol decl for deferred character length array references. * trans-stmt.c (gfc_trans_allocate): Keep the string lengths to update deferred length character string lengths. * trans-types.c (gfc_get_dtype_rank_type); Use the string length of deferred character types for the dtype size. * trans.c (gfc_build_array_ref): For references to deferred character arrays, use the domain max value, if it is a variable to set the 'span' and use pointer arithmetic for acces to the element. (trans_code): Set gfc_current_locus for diagnostic purposes. PR fortran/67674 * trans-expr.c (gfc_conv_procedure_call): Do not fix deferred string lengths of components. PR fortran/49954 * resolve.c (deferred_op_assign): New function. (gfc_resolve_code): Call it. * trans-array.c (concat_str_length): New function. (gfc_alloc_allocatable_for_assignment): Jump directly to alloc/ realloc blocks for deferred character length arrays because the string length might change, even if the shape is the same. Call concat_str_length to obtain the string length for concatenation since it is needed to compute the lhs string length. Set the descriptor dtype appropriately for the new string length. * trans-expr.c (gfc_trans_assignment_1): Use the rse string length for all characters, other than deferred types. For concatenation operators, push the rse.pre block to the inner most loop so that the temporary pointer and the assignments are properly placed. 2015-11-15 Paul Thomas PR fortran/50221 * gfortran.dg/deferred_character_1.f90: New test. * gfortran.dg/deferred_character_4.f90: New test for comment #4 of the PR. PR fortran/68216 * gfortran.dg/deferred_character_2.f90: New test. PR fortran/67674 * gfortran.dg/deferred_character_3.f90: New test. PR fortran/63932 * gfortran.dg/deferred_character_5.f90: New test. PR fortran/66408 * gfortran.dg/deferred_character_6.f90: New test. PR fortran/49954 * gfortran.dg/deferred_character_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_1.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_2.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_3.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_5.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_6.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/67674] Incorrect result or ICE for deferred-length character component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67674 --- Comment #2 from Paul Thomas --- Author: pault Date: Sun Nov 15 14:07:52 2015 New Revision: 230396 URL: https://gcc.gnu.org/viewcvs?rev=230396&root=gcc&view=rev Log: 2015-11-15 Paul Thomas PR fortran/50221 PR fortran/68216 PR fortran/63932 PR fortran/66408 * trans_array.c (gfc_conv_scalarized_array_ref): Pass the symbol decl for deferred character length array references. * trans-stmt.c (gfc_trans_allocate): Keep the string lengths to update deferred length character string lengths. * trans-types.c (gfc_get_dtype_rank_type); Use the string length of deferred character types for the dtype size. * trans.c (gfc_build_array_ref): For references to deferred character arrays, use the domain max value, if it is a variable to set the 'span' and use pointer arithmetic for acces to the element. (trans_code): Set gfc_current_locus for diagnostic purposes. PR fortran/67674 * trans-expr.c (gfc_conv_procedure_call): Do not fix deferred string lengths of components. PR fortran/49954 * resolve.c (deferred_op_assign): New function. (gfc_resolve_code): Call it. * trans-array.c (concat_str_length): New function. (gfc_alloc_allocatable_for_assignment): Jump directly to alloc/ realloc blocks for deferred character length arrays because the string length might change, even if the shape is the same. Call concat_str_length to obtain the string length for concatenation since it is needed to compute the lhs string length. Set the descriptor dtype appropriately for the new string length. * trans-expr.c (gfc_trans_assignment_1): Use the rse string length for all characters, other than deferred types. For concatenation operators, push the rse.pre block to the inner most loop so that the temporary pointer and the assignments are properly placed. 2015-11-15 Paul Thomas PR fortran/50221 * gfortran.dg/deferred_character_1.f90: New test. * gfortran.dg/deferred_character_4.f90: New test for comment #4 of the PR. PR fortran/68216 * gfortran.dg/deferred_character_2.f90: New test. PR fortran/67674 * gfortran.dg/deferred_character_3.f90: New test. PR fortran/63932 * gfortran.dg/deferred_character_5.f90: New test. PR fortran/66408 * gfortran.dg/deferred_character_6.f90: New test. PR fortran/49954 * gfortran.dg/deferred_character_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_1.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_2.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_3.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_5.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_6.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68216 --- Comment #9 from Paul Thomas --- Author: pault Date: Sun Nov 15 14:07:52 2015 New Revision: 230396 URL: https://gcc.gnu.org/viewcvs?rev=230396&root=gcc&view=rev Log: 2015-11-15 Paul Thomas PR fortran/50221 PR fortran/68216 PR fortran/63932 PR fortran/66408 * trans_array.c (gfc_conv_scalarized_array_ref): Pass the symbol decl for deferred character length array references. * trans-stmt.c (gfc_trans_allocate): Keep the string lengths to update deferred length character string lengths. * trans-types.c (gfc_get_dtype_rank_type); Use the string length of deferred character types for the dtype size. * trans.c (gfc_build_array_ref): For references to deferred character arrays, use the domain max value, if it is a variable to set the 'span' and use pointer arithmetic for acces to the element. (trans_code): Set gfc_current_locus for diagnostic purposes. PR fortran/67674 * trans-expr.c (gfc_conv_procedure_call): Do not fix deferred string lengths of components. PR fortran/49954 * resolve.c (deferred_op_assign): New function. (gfc_resolve_code): Call it. * trans-array.c (concat_str_length): New function. (gfc_alloc_allocatable_for_assignment): Jump directly to alloc/ realloc blocks for deferred character length arrays because the string length might change, even if the shape is the same. Call concat_str_length to obtain the string length for concatenation since it is needed to compute the lhs string length. Set the descriptor dtype appropriately for the new string length. * trans-expr.c (gfc_trans_assignment_1): Use the rse string length for all characters, other than deferred types. For concatenation operators, push the rse.pre block to the inner most loop so that the temporary pointer and the assignments are properly placed. 2015-11-15 Paul Thomas PR fortran/50221 * gfortran.dg/deferred_character_1.f90: New test. * gfortran.dg/deferred_character_4.f90: New test for comment #4 of the PR. PR fortran/68216 * gfortran.dg/deferred_character_2.f90: New test. PR fortran/67674 * gfortran.dg/deferred_character_3.f90: New test. PR fortran/63932 * gfortran.dg/deferred_character_5.f90: New test. PR fortran/66408 * gfortran.dg/deferred_character_6.f90: New test. PR fortran/49954 * gfortran.dg/deferred_character_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_1.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_2.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_3.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_5.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_6.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50221] Allocatable string length fails with array assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221 --- Comment #7 from Paul Thomas --- Author: pault Date: Sun Nov 15 14:07:52 2015 New Revision: 230396 URL: https://gcc.gnu.org/viewcvs?rev=230396&root=gcc&view=rev Log: 2015-11-15 Paul Thomas PR fortran/50221 PR fortran/68216 PR fortran/63932 PR fortran/66408 * trans_array.c (gfc_conv_scalarized_array_ref): Pass the symbol decl for deferred character length array references. * trans-stmt.c (gfc_trans_allocate): Keep the string lengths to update deferred length character string lengths. * trans-types.c (gfc_get_dtype_rank_type); Use the string length of deferred character types for the dtype size. * trans.c (gfc_build_array_ref): For references to deferred character arrays, use the domain max value, if it is a variable to set the 'span' and use pointer arithmetic for acces to the element. (trans_code): Set gfc_current_locus for diagnostic purposes. PR fortran/67674 * trans-expr.c (gfc_conv_procedure_call): Do not fix deferred string lengths of components. PR fortran/49954 * resolve.c (deferred_op_assign): New function. (gfc_resolve_code): Call it. * trans-array.c (concat_str_length): New function. (gfc_alloc_allocatable_for_assignment): Jump directly to alloc/ realloc blocks for deferred character length arrays because the string length might change, even if the shape is the same. Call concat_str_length to obtain the string length for concatenation since it is needed to compute the lhs string length. Set the descriptor dtype appropriately for the new string length. * trans-expr.c (gfc_trans_assignment_1): Use the rse string length for all characters, other than deferred types. For concatenation operators, push the rse.pre block to the inner most loop so that the temporary pointer and the assignments are properly placed. 2015-11-15 Paul Thomas PR fortran/50221 * gfortran.dg/deferred_character_1.f90: New test. * gfortran.dg/deferred_character_4.f90: New test for comment #4 of the PR. PR fortran/68216 * gfortran.dg/deferred_character_2.f90: New test. PR fortran/67674 * gfortran.dg/deferred_character_3.f90: New test. PR fortran/63932 * gfortran.dg/deferred_character_5.f90: New test. PR fortran/66408 * gfortran.dg/deferred_character_6.f90: New test. PR fortran/49954 * gfortran.dg/deferred_character_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_1.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_2.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_3.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_5.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_6.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66408] deferred-length character & overloaded assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66408 --- Comment #3 from Paul Thomas --- Author: pault Date: Sun Nov 15 14:07:52 2015 New Revision: 230396 URL: https://gcc.gnu.org/viewcvs?rev=230396&root=gcc&view=rev Log: 2015-11-15 Paul Thomas PR fortran/50221 PR fortran/68216 PR fortran/63932 PR fortran/66408 * trans_array.c (gfc_conv_scalarized_array_ref): Pass the symbol decl for deferred character length array references. * trans-stmt.c (gfc_trans_allocate): Keep the string lengths to update deferred length character string lengths. * trans-types.c (gfc_get_dtype_rank_type); Use the string length of deferred character types for the dtype size. * trans.c (gfc_build_array_ref): For references to deferred character arrays, use the domain max value, if it is a variable to set the 'span' and use pointer arithmetic for acces to the element. (trans_code): Set gfc_current_locus for diagnostic purposes. PR fortran/67674 * trans-expr.c (gfc_conv_procedure_call): Do not fix deferred string lengths of components. PR fortran/49954 * resolve.c (deferred_op_assign): New function. (gfc_resolve_code): Call it. * trans-array.c (concat_str_length): New function. (gfc_alloc_allocatable_for_assignment): Jump directly to alloc/ realloc blocks for deferred character length arrays because the string length might change, even if the shape is the same. Call concat_str_length to obtain the string length for concatenation since it is needed to compute the lhs string length. Set the descriptor dtype appropriately for the new string length. * trans-expr.c (gfc_trans_assignment_1): Use the rse string length for all characters, other than deferred types. For concatenation operators, push the rse.pre block to the inner most loop so that the temporary pointer and the assignments are properly placed. 2015-11-15 Paul Thomas PR fortran/50221 * gfortran.dg/deferred_character_1.f90: New test. * gfortran.dg/deferred_character_4.f90: New test for comment #4 of the PR. PR fortran/68216 * gfortran.dg/deferred_character_2.f90: New test. PR fortran/67674 * gfortran.dg/deferred_character_3.f90: New test. PR fortran/63932 * gfortran.dg/deferred_character_5.f90: New test. PR fortran/66408 * gfortran.dg/deferred_character_6.f90: New test. PR fortran/49954 * gfortran.dg/deferred_character_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_1.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_2.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_3.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_5.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_6.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/49954] ICE assigning concat expression to an array deferred-length string (realloc on assignment)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954 --- Comment #4 from Paul Thomas --- Author: pault Date: Sun Nov 15 14:07:52 2015 New Revision: 230396 URL: https://gcc.gnu.org/viewcvs?rev=230396&root=gcc&view=rev Log: 2015-11-15 Paul Thomas PR fortran/50221 PR fortran/68216 PR fortran/63932 PR fortran/66408 * trans_array.c (gfc_conv_scalarized_array_ref): Pass the symbol decl for deferred character length array references. * trans-stmt.c (gfc_trans_allocate): Keep the string lengths to update deferred length character string lengths. * trans-types.c (gfc_get_dtype_rank_type); Use the string length of deferred character types for the dtype size. * trans.c (gfc_build_array_ref): For references to deferred character arrays, use the domain max value, if it is a variable to set the 'span' and use pointer arithmetic for acces to the element. (trans_code): Set gfc_current_locus for diagnostic purposes. PR fortran/67674 * trans-expr.c (gfc_conv_procedure_call): Do not fix deferred string lengths of components. PR fortran/49954 * resolve.c (deferred_op_assign): New function. (gfc_resolve_code): Call it. * trans-array.c (concat_str_length): New function. (gfc_alloc_allocatable_for_assignment): Jump directly to alloc/ realloc blocks for deferred character length arrays because the string length might change, even if the shape is the same. Call concat_str_length to obtain the string length for concatenation since it is needed to compute the lhs string length. Set the descriptor dtype appropriately for the new string length. * trans-expr.c (gfc_trans_assignment_1): Use the rse string length for all characters, other than deferred types. For concatenation operators, push the rse.pre block to the inner most loop so that the temporary pointer and the assignments are properly placed. 2015-11-15 Paul Thomas PR fortran/50221 * gfortran.dg/deferred_character_1.f90: New test. * gfortran.dg/deferred_character_4.f90: New test for comment #4 of the PR. PR fortran/68216 * gfortran.dg/deferred_character_2.f90: New test. PR fortran/67674 * gfortran.dg/deferred_character_3.f90: New test. PR fortran/63932 * gfortran.dg/deferred_character_5.f90: New test. PR fortran/66408 * gfortran.dg/deferred_character_6.f90: New test. PR fortran/49954 * gfortran.dg/deferred_character_7.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/deferred_character_1.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_2.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_3.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_4.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_5.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_6.f90 trunk/gcc/testsuite/gfortran.dg/deferred_character_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328 --- Comment #3 from Mikael Pettersson --- I'm on Fedora 20 / x86_64 (Ivy Bridge i7-3770K) w/ the 4.3 Linux kernel. I've tried various combinations of bootstrap compiler (system gcc-4.8.3 or my own gcc-4.9.3 + patches), support libraries (system gmp/mpfr/mpc/cloog/isl or my own), and w/ or w/o cloog/isl. No combination triggered the wrong-code you see. Could someone else please have a go at reproducing this?
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #25 from Markus Trippelsdorf --- I think the issue is caused by Richi's r229405. In this patch the following two lines were accidentally removed from tree-ssa.c (delete_tree_ssa): - /* We no longer need the edge variable maps. */ - redirect_edge_var_map_destroy (); Restoring them fixes the bug for me: diff --git a/gcc/tree-ssa.c b/gcc/tree-ssa.c index 84a4d5b..02fca4c 100644 --- a/gcc/tree-ssa.c +++ b/gcc/tree-ssa.c @@ -1126,6 +1126,9 @@ delete_tree_ssa (struct function *fn) fn->gimple_df->decls_to_pointers = NULL; fn->gimple_df->modified_noreturn_calls = NULL; fn->gimple_df = NULL; + + /* We no longer need the edge variable maps. */ + redirect_edge_var_map_destroy (); } /* Return true if EXPR is a useless type conversion, otherwise return
[Bug c/68360] New: GCC bitfield processing code is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360
Bug ID: 68360
Summary: GCC bitfield processing code is very inefficient
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vorfeed.canal at gmail dot com
Target Milestone: ---
It looks like GCC couldn't generate efficient code where clang could. I'm not
talking about something extremely complicated - just the code where few bits
must be copied without modifications.
E.g.
$ cat test.c
#include
struct test {
unsigned :32;
unsigned :2;
unsigned a:2;
unsigned :2;
unsigned b:1;
unsigned :1;
};
void bar(struct test*);
void foo(unsigned int i) {
struct test a;
a.a = (i >> 2) & 0x3;
a.b = (i >> 6) & 0x1;
bar(&a);
}
$ clang -O3 -S test2.c -o-
.text
.file "test2.c"
.globl foo
.align 16, 0x90
.type foo,@function
foo:# @foo
# BB#0:
subl$28, %esp
movl32(%esp), %eax
andl$76, %eax
movl%eax, 20(%esp)
movl$0, 16(%esp)
leal16(%esp), %eax
movl%eax, (%esp)
calll bar
addl$28, %esp
retl
.Lfunc_end0:
.size foo, .Lfunc_end0-foo
.ident "clang version 3.6 "
.section".note.GNU-stack","",@progbits
$ g++ -O3 -S test2.c -o-
.file "test2.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl _Z3fooj
.type _Z3fooj, @function
_Z3fooj:
.LFB14:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl%edi, %edx
shrl$6, %edi
movzbl 4(%rsp), %ecx
shrl$2, %edx
andl$1, %edi
andl$3, %edx
movl%edi, %eax
sall$2, %edx
sall$6, %eax
andl$-77, %ecx
orl %edx, %ecx
movl%ecx, %edi
orl %eax, %edi
movb%dil, 4(%rsp)
movq%rsp, %rdi
call_Z3barP4test
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE14:
.size _Z3fooj, .-_Z3fooj
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (GNU) 5.2.0"
.section.note.GNU-stack,"",@progbits
[Bug bootstrap/68361] New: [6 regression] Bootstrap failure with --enable-checking=release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68361 Bug ID: 68361 Summary: [6 regression] Bootstrap failure with --enable-checking=release Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: jason at gcc dot gnu.org, mpolacek at gcc dot gnu.org Target Milestone: --- When building with --enable-checking=release: ../../gcc/gcc/cp/tree.c: In function ‘tree_node* build_cplus_array_type(tree, tree)’: ../../gcc/gcc/cp/tree.c:894:44: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] = TYPE_NEEDS_CONSTRUCTING (elt_type)); ^ ../../gcc/gcc/cp/tree.c:896:51: error: suggest parentheses around assignment used as truth value [-Werror=parentheses] = TYPE_HAS_NONTRIVIAL_DESTRUCTOR (elt_type)); ^
[Bug bootstrap/68361] [6 regression] Bootstrap failure with --enable-checking=release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68361 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |6.0
[Bug libfortran/68115] [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68115 John David Anglin changed: What|Removed |Added CC||ian at airs dot com --- Comment #4 from John David Anglin --- Well no, it exposes another issue in stage3: /bin/sh ./libtool --tag=CC --mode=compile /test/gnu/gcc/objdir/./gcc/xgcc -B/t est/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/bin/ -B/opt /gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-6/hppa64-h p-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/sys-includ e-DHAVE_CONFIG_H -I. -I../../../gcc/libbacktrace -I ../../../gcc/libbacktra ce/../include -I ../../../gcc/libbacktrace/../libgcc -I ../libgcc -funwind-tabl es -frandom-seed=elf.lo -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-p rototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -c -o elf.lo ../../../gcc/libbacktrace/elf.c libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-6/hppa64-h p-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/include -isys tem /opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I. -I. ./../../gcc/libbacktrace -I ../../../gcc/libbacktrace/../include -I ../../../gcc /libbacktrace/../libgcc -I ../libgcc -funwind-tables -frandom-seed=elf.lo -W -Wa ll -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definiti on -Wmissing-format-attribute -Wcast-qual -Werror -g -O2 -c ../../../gcc/libback trace/elf.c -DPIC -o .libs/elf.o In file included from ../../../gcc/libbacktrace/elf.c:44:0: ../../../gcc/libbacktrace/elf.c: In function 'backtrace_initialize': ../../../gcc/libbacktrace/internal.h:64:55: error: right-hand operand of comma e xpression has no effect [-Werror=unused-value] #define __sync_bool_compare_and_swap(A, B, C) (abort(), 1) ^ ../../../gcc/libbacktrace/elf.c:958:2: note: in expansion of macro '__sync_bool_compare_and_swap' __sync_bool_compare_and_swap (&state->syminfo_fn, NULL, elf_nosyms); ^ cc1: all warnings being treated as errors make[3]: *** [elf.lo] Error 1 There are no HAVE_SYNC_FUNCTIONS checks in libbacktrace/elf.c to avoid use of __sync functions.
[Bug libfortran/68115] [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68115 --- Comment #5 from Ian Lance Taylor --- The HAVE_SYNC_FUNCTIONS test is in libbacktrace/internal.h, and it #define's the functions. You can see that that is happening because the warning is about a macro expansion. It looks like we just need to add some sort of cast to disable the warning in this specific case. For the use when target_subdir is set, my understanding has been that targets will either define the sync builtins directly or provide a version in the support libraries. If that is not the case, then we need to edit libbacktrace/configure.ac to recognize some cases where the sync functions are not available.
[Bug libfortran/68115] [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68115 --- Comment #6 from dave.anglin at bell dot net --- On 2015-11-15, at 10:46 AM, ian at airs dot com wrote: > The HAVE_SYNC_FUNCTIONS test is in libbacktrace/internal.h, and it #define's > the functions. You can see that that is happening because the warning is > about > a macro expansion. It looks like we just need to add some sort of cast to > disable the warning in this specific case. What about using "#pragma GCC diagnostic"? -- John David Anglin dave.ang...@bell.net
[Bug c++/68362] New: [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362
Bug ID: 68362
Summary: [6 Regression] ICE: tree check: expected integer_cst,
have nop_expr in get_val, at tree.h:5157
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
trippels@gcc2-power8 generic % cat nsLineLayout.ii
enum class A { foo };
void fn1(const A test) {
switch (test)
case A::foo: ;
}
trippels@gcc2-power8 generic % g++ -c nsLineLayout.ii
nsLineLayout.ii: In function ‘void fn1(A)’:
nsLineLayout.ii:4:11: internal compiler error: tree check: expected
integer_cst, have nop_expr in get_val, at tree.h:5157
case A::foo: ;
^~~
0x10d9ee93 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9587
0x10120d9b tree_int_cst_elt_check
../../gcc/gcc/tree.h:3144
0x104a9c8f tree_int_cst_elt_check
../../gcc/gcc/tree.h:3147
0x104a9c8f wi::extended_tree<192>::get_val() const
../../gcc/gcc/tree.h:5157
0x104a9c8f wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/gcc/wide-int.h:898
0x104a9c8f wide_int_ref_storage > >
../../gcc/gcc/wide-int.h:945
0x104a9c8f generic_wide_int > >
../../gcc/gcc/wide-int.h:722
0x104a9c8f lts_p >,
generic_wide_int > >
../../gcc/gcc/wide-int.h:1749
0x104a9c8f tree_int_cst_lt
../../gcc/gcc/tree.h:5217
0x104a9c8f c_add_case_label(unsigned int, splay_tree_s*, tree_node*,
tree_node*, tree_node*, tree_node*, bool*)
../../gcc/gcc/c-family/c-common.c:6592
0x1019f217 finish_case_label(unsigned int, tree_node*, tree_node*)
../../gcc/gcc/cp/decl.c:3417
0x102fb753 cp_parser_label_for_labeled_statement
../../gcc/gcc/cp/parser.c:10259
0x102e4ca3 cp_parser_statement
../../gcc/gcc/cp/parser.c:10132
0x1031e23b cp_parser_implicitly_scoped_statement
../../gcc/gcc/cp/parser.c:11557
0x102e56d3 cp_parser_selection_statement
../../gcc/gcc/cp/parser.c:10632
0x102e56d3 cp_parser_statement
../../gcc/gcc/cp/parser.c:10040
0x102e6617 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10456
0x102e67ef cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10410
0x1031325b cp_parser_function_body
../../gcc/gcc/cp/parser.c:20225
0x1031325b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:20261
[Bug fortran/38115] unneeded temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from Thomas Koenig --- The temporary in Comment#2 is now also removed by the middle-end. The front end still warns about this, but I think that this is something that we can live with. Closing as FIXED.
[Bug fortran/36854] [meta-bug] fortran front-end optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854 Bug 36854 depends on bug 38115, which changed state. Bug 38115 Summary: unneeded temp https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/68363] New: [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68363 Bug ID: 68363 Summary: [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Created attachment 36714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36714&action=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -mfix-cortex-a53-835769 testcase.c testcase.c: In function 'foo': testcase.c:16:1: internal compiler error: RTL check: expected elt 5 type 'i' or 'n', have '0' (rtx jump_table_data) in recog_memoized, at recog.h:167 } ^ 0xaa6796 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl.c:802 0xe4ea6e recog_memoized /mnt/svn/gcc-trunk/gcc/recog.h:169 0xe4ea6e aarch64_madd_needs_nop(rtx_insn*) /mnt/svn/gcc-trunk/gcc/config/aarch64/aarch64.c:10079 0x7f73c3 shorten_branches(rtx_insn*) /mnt/svn/gcc-trunk/gcc/final.c:1189 0x7f8e3f rest_of_handle_shorten_branches /mnt/svn/gcc-trunk/gcc/final.c:4527 0x7f8e3f execute /mnt/svn/gcc-trunk/gcc/final.c:4556 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. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-230394-checking-yes-rtl-df-nographite-aarch64/libexec/gcc/aarch64-unknown-linux-gnu/6.0.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++ --prefix=/mnt/svn/gcc-trunk/binary-230394-checking-yes-rtl-df-nographite-aarch64/ --without-cloog --without-ppl --without-isl --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --with-sysroot=/home/aarch64-chroot --with-as=/usr/libexec/gcc/aarch64-unknown-linux-gnu/as --with-ld=/usr/libexec/gcc/aarch64-unknown-linux-gnu/ld Thread model: posix gcc version 6.0.0 20151115 (experimental) (GCC) RTL checking must be enabled. Tested revisions: trunk r230394 - ICE 5-branch r229483 - ICE 4_9-branch r229291 - ICE 4_8-branch r224828 - OK
[Bug c++/68364] New: ICE in tree_check()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68364 Bug ID: 68364 Summary: ICE in tree_check() Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- Created attachment 36715 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36715&action=edit Test case (derived from ScyllaDB; AGPL) g++6 (GCC) 6.0.0 20151113 (experimental) Copyright (C) 2015 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. 5f3001a9d4fa4beb4418b8e7465a0f0f7349eaea In file included from ./exceptions/exceptions.hh:45:0, from ./compress.hh:24, from ./schema.hh:37, from ./cql3/selection/selectable.hh:45, from ./cql3/selection/writetime_or_ttl.hh:45, from build/release/gen/cql3/CqlParser.hpp:63, from build/release/gen/cql3/CqlParser.cpp:44: ./db/write_type.hh: In function ‘std::ostream& db::operator<<(std::ostream&, const db::write_type&)’: ./db/write_type.hh:58:19: internal compiler error: tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5167 case write_type::SIMPLE: os << "SIMPLE"; break; ^~ 0xf366dc tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9587 0x825308 tree_check ../../gcc/tree.h:3212 0x825308 wi::extended_tree<192>::get_len() const ../../gcc/tree.h:5167 0x825308 wi::int_traits > >::decompose(long*, unsigned int, generic_wide_int > const&) ../../gcc/wide-int.h:898 0x825308 wide_int_ref_storage > > ../../gcc/wide-int.h:945 0x825308 generic_wide_int > > ../../gcc/wide-int.h:722 0x825308 cmps >, generic_wide_int > > ../../gcc/wide-int.h:1900 0x825308 tree_int_cst_compare ../../gcc/tree.h:5236 0x825308 c_add_case_label(unsigned int, splay_tree_s*, tree_node*, tree_node*, tree_node*, tree_node*, bool*) ../../gcc/c-family/c-common.c:6634 0x5b87e3 finish_case_label(unsigned int, tree_node*, tree_node*) ../../gcc/cp/decl.c:3417 0x6d202a cp_parser_label_for_labeled_statement ../../gcc/cp/parser.c:10259 0x6c0030 cp_parser_statement ../../gcc/cp/parser.c:10132 0x6c16ac cp_parser_statement_seq_opt ../../gcc/cp/parser.c:10456 0x6c180e cp_parser_compound_statement ../../gcc/cp/parser.c:10410 0x6ecaec cp_parser_implicitly_scoped_statement ../../gcc/cp/parser.c:11550 0x6c09af cp_parser_selection_statement ../../gcc/cp/parser.c:10632 0x6c09af cp_parser_statement ../../gcc/cp/parser.c:10040 0x6c16ac cp_parser_statement_seq_opt ../../gcc/cp/parser.c:10456 0x6c180e cp_parser_compound_statement ../../gcc/cp/parser.c:10410 0x6e4c5b cp_parser_function_body ../../gcc/cp/parser.c:20225 Please submit a full bug report, with preprocessed source if appropriate. Compile attached file with -std=gnu++1y -march=nehalem (needed due to intrinsics included)
[Bug c++/68364] ICE in tree_check()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68364 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 68362 ***
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Markus Trippelsdorf changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #1 from Markus Trippelsdorf --- *** Bug 68364 has been marked as a duplicate of this bug. ***
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 --- Comment #19 from Magnus Fromreide --- When you say "latest openssl", do you refer to trunk or 1.0.2d? It seems that the problem is gone from openssl trunk due to a source reorganization but it seems to still be present in 1.0.2d.
[Bug fortran/68365] New: gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 Bug ID: 68365 Summary: gfortran test case showing performance loss with vectorization Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tprince at computer dot org Target Milestone: --- Created attachment 36716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36716&action=edit gzip tar file of Fortran and C source files Just recently, it has become necessary to add the omp simd safelen(1) directive in subroutine s111 in order to prevent a vectorization which reduces performance on all known IA targets other than Intel Xeon Phi. The same situation occurs in gcc/g++, and (for several years) icc/icpc (but not ifort). make -j 3 -f Makefile.cygwin lcd_ffast I haven't tested the latest gfortran build on linux, but I do have a Makefile for that, in case it's useful. In the Makefile, CLOCK_RATE is set to enable accurate translation from rdtsc ticks to seconds. The timing quotations for VL=100 and VL=1000 will show the reduced performance of s111 when vectorized by removing safelen(1) . For gcc and g++, functions s128() and s4113() also need vectorization disable for full performance, but gfortran doesn't exhibit that problem. For this filing, you can ignore everything but subroutine s111.
[Bug fortran/68365] gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-15 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- make: *** No rule to make target 'lcdmod.o', needed by 'lcd_mod.mod'. Stop. or Fatal Error: Can't open module file 'lcd_mod.mod' for reading at (1): No such file or directory What should be done for non cygwin platform?
[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Can you please bisect SVN revision that is responsible for these failures? Thanks, Martin
[Bug middle-end/68366] New: [6 Regression] sdbout.c build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68366 Bug ID: 68366 Summary: [6 Regression] sdbout.c build error Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: tsaunders at mozilla dot com Target Milestone: --- Host: hppa*-*-* Target: hppa*-*-* Build: hppa*-*-* Created attachment 36717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36717&action=edit Preprocessed source g++ -std=gnu++98 -fno-PIE -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-f ormat -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long - Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gc c/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I./../intl -I../../gcc/gcc/. ./libcpp/include -I/opt/gnu64/gcc/gmp/include -I../../gcc/gcc/../libdecnumber - I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o sdbout.o -MT sdbout.o -MMD -MP -MF ./.deps/sdbout.TPo ../../gcc/gcc/sd bout.c ../../gcc/gcc/sdbout.c: In function 'void sdbout_symbol(tree, int)': ../../gcc/gcc/config/pa/pa.h:168:8: error: 'frame_pointer_needed' was not declar ed in this scope + (frame_pointer_needed ? 0 : pa_compute_frame_size (get_frame_size (), 0))) ^ ../../gcc/gcc/sdbout.c:163:23: note: in definition of macro 'PUT_SDB_INT_VAL' (HOST_WIDE_INT) (a), SDB_DELIM);\ ^ ../../gcc/gcc/sdbout.c:853:25: note: in expansion of macro 'DEBUGGER_AUTO_OFFSET' PUT_SDB_INT_VAL (DEBUGGER_AUTO_OFFSET ^ ../../gcc/gcc/config/pa/pa.h:168:74: error: 'get_frame_size' was not declared in this scope + (frame_pointer_needed ? 0 : pa_compute_frame_size (get_frame_size (), 0))) ^
[Bug middle-end/68360] GCC bitfield processing code is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 --- Comment #1 from Andrew Pinski --- For AARCH64 GCC does a much better job: foo: stp x29, x30, [sp, -32]! add x29, sp, 0 ldrbw1, [x29,28] lsr w2, w0, 2 bfi w1, w2, 2, 2 lsr w0, w0, 6 bfi w1, w0, 6, 1 add x0, x29, 24 strbw1, [x29,28] bl bar But there is still some things missing but it is still a much better job than what happens on x86.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Alexander Cherepanov changed:
What|Removed |Added
CC||ch3root at openwall dot com
--- Comment #38 from Alexander Cherepanov ---
IMHO this bug is not specific to integers and boils down to this: when a check
for equality ignores provenance for some reason, phiopt nevertheless will
replace one variable by another with the wrong provenance.
Integers are surely compared without regard to prevenance. That's one case.
Another case is a comparison of two pointers when one of the lost its
provenance info. E.g. the program (somewhat based on pr61502):
#include
#include
int main()
{
int y, x = 0;
int *volatile v = &x;
int *xp = v;
int *i = &y + 1;
if (xp != i) {
printf("hello\n");
xp = i;
}
*xp = 15;
printf("%d\n", x);
}
prints 0 for me with gcc 5.2.0 -O2.
The evident solution is to not apply this optimization when provenance info of
the two variables differs. I guess for most integers it will be the same.
Additionally, this optimization could be applied when provenance info for the
first variable is known but it's unknown for the second one. This leads to the
loss of provenance info and can prevent other optimizations.
Maybe a more complex solution is possible, like tracking provenance info
separately from the core value, I don't know.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #39 from Andrew Pinski ---
(In reply to Alexander Cherepanov from comment #38)
> IMHO this bug is not specific to integers and boils down to this: when a
> check for equality ignores provenance for some reason, phiopt nevertheless
> will replace one variable by another with the wrong provenance.
>
> Integers are surely compared without regard to prevenance. That's one case.
> Another case is a comparison of two pointers when one of the lost its
> provenance info. E.g. the program (somewhat based on pr61502):
>
> #include
> #include
>
> int main()
> {
> int y, x = 0;
> int *volatile v = &x;
> int *xp = v;
> int *i = &y + 1;
>
> if (xp != i) {
> printf("hello\n");
> xp = i;
> }
>
> *xp = 15;
>
> printf("%d\n", x);
> }
>
> prints 0 for me with gcc 5.2.0 -O2.
Except the above testcase is invalid/undefined as &y + 1 is undefined if
deferenced and &x and &y + 1 cannot be compared in a defined sense as both
deals with two different arrays.
[Bug ipa/68367] New: ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 Bug ID: 68367 Summary: ICE in vectorizable_load, at tree-vect-stmts.c:6711 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Created attachment 36718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36718&action=edit matmul_i4.i Since r230311: PR ipa/68311 * ipa-icf.c (sem_item_optimizer::traverse_congruence_split): Replace ctor with auto_vec and initialization in a loop. I noticed an ICE in vectorizable_load, at tree-vect-stmts.c:6711 when compiling libgfortran (libgfortran/generated/matmul_i4.c). I observed this when gcc is configured with: --target=armeb-none-linux-gnueabihf --with-float=hard --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon Using --target=arm-none-linux-gnueabihf works. The backtrace is: /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/libgfortran/generated/matmul_i4.c: In function 'matmul_i4': /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/libgfortran/generated/matmul_i4.c:79:1: internal compiler error: in vectorizable_load, at tree-vect-stmts.c:6711 matmul_i4 (gfc_array_i4 * const restrict retarray, ^ 0xfeb563 vectorizable_load /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree-vect-stmts.c:6711 0xfef559 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree-vect-stmts.c:8002 0x10074d5 vect_transform_loop(_loop_vec_info*) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree-vect-loop.c:6793 0x101e3ef vectorize_loops() /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree-vectorizer.c:548 0xf019ab execute /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree-ssa-loop.c:273 Please submit a full bug report, Using options -ftree-vectorize -O2 is sufficient to create the ICE.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #40 from Alexander Cherepanov ---
Ok, this program:
#include
#include
int main() {
int y, x = 0;
int *volatile v = &x;
int *xp = v;
int *i = &y + 1;
if (xp != i) {
printf("hello\n");
xp = i;
}
printf("%d\n", xp == &x);
}
print 0 too even though it should print 1.
[Bug c++/68368] New: [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68368 Bug ID: 68368 Summary: [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Created attachment 36719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36719&action=edit eh_personality.ii I've noticed this ICE while building GCC: /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/libstdc++-v3/libsupc++/eh_personality.cc: In function '_Unwind_Reason_Code __cxxabiv1::__gxx_personality_v0(_Unwind_State, _Unwind_Control_Block*, _Unwind_Context*)': /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/libstdc++-v3/libsupc++/eh_personality.cc:394:25: internal compiler error: tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123 UNWIND_STACK_REG)) ^ 0x12c5f26 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree.c:9587 0x6b0fe1 tree_check(tree_node const*, char const*, int, char const*, tree_code) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree.h:3212 0x7208bc wi::int_traits::decompose(long*, unsigned int, tree_node const*) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/tree.h:5123 0x897672 wide_int_ref_storage::wide_int_ref_storage(tree_node* const&) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/wide-int.h:936 0x897630 generic_wide_int >::generic_wide_int(tree_node* const&) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/wide-int.h:714 0x1442950 generic_simplify_172 /home/christophe.lyon/src/GCC/builds/gcc-fsf-trunk-for-crontab/obj-arm-none-eabi/gcc3/gcc/generic-match.c:6142 0x14808ae generic_simplify_EQ_EXPR /home/christophe.lyon/src/GCC/builds/gcc-fsf-trunk-for-crontab/obj-arm-none-eabi/gcc3/gcc/generic-match.c:22841 0x1487045 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /home/christophe.lyon/src/GCC/builds/gcc-fsf-trunk-for-crontab/obj-arm-none-eabi/gcc3/gcc/generic-match.c:25312 0xc10ff8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/fold-const.c:9138 0xc219d4 fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/fold-const.c:12333 0x142fadd generic_simplify_46 /home/christophe.lyon/src/GCC/builds/gcc-fsf-trunk-for-crontab/obj-arm-none-eabi/gcc3/gcc/generic-match.c:2014 0x147f74a generic_simplify_EQ_EXPR /home/christophe.lyon/src/GCC/builds/gcc-fsf-trunk-for-crontab/obj-arm-none-eabi/gcc3/gcc/generic-match.c:22441 0x1487045 generic_simplify(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /home/christophe.lyon/src/GCC/builds/gcc-fsf-trunk-for-crontab/obj-arm-none-eabi/gcc3/gcc/generic-match.c:25312 0xc10ff8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/fold-const.c:9138 0xc215cb fold(tree_node*) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/fold-const.c:11973 0x6c4ede build_new_op_1 /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/cp/call.c:5730 0x6c50c6 build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*, tree_node*, tree_node**, int) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/cp/call.c:5803 0x87bddf build_x_binary_op(unsigned int, tree_code, tree_node*, tree_code, tree_node*, tree_code, tree_node**, int) /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/cp/typeck.c:3828 0x81cdf4 cp_parser_binary_expression /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/cp/parser.c:8621 0x81d0fd cp_parser_assignment_expression /home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/cp/parser.c:8742 Please submit a full bug report, No optimization flag is needed to trigger the ICE. GCC is configured as: --target=arm-none-eabi --with-newlib --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon I noticed this problem with bare-metal ARM targets (using Newlib). arm-linux targets (using glibc) are OK.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #41 from Andrew Pinski ---
(In reply to Alexander Cherepanov from comment #40)
> Ok, this program:
>
> #include
> #include
>
> int main() {
>int y, x = 0;
>int *volatile v = &x;
>int *xp = v;
>int *i = &y + 1;
>
>if (xp != i) {
> printf("hello\n");
> xp = i;
>}
>
>printf("%d\n", xp == &x);
> }
>
Still undefined as &x and &y + 1 are not comparable.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #42 from Alexander Cherepanov ---
On 2015-11-16 00:48, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
>
> --- Comment #41 from Andrew Pinski ---
> (In reply to Alexander Cherepanov from comment #40)
>> Ok, this program:
>>
>> #include
>> #include
>>
>> int main() {
>> int y, x = 0;
>> int *volatile v = &x;
>> int *xp = v;
>> int *i = &y + 1;
>>
>> if (xp != i) {
>> printf("hello\n");
>> xp = i;
>> }
>>
>> printf("%d\n", xp == &x);
>> }
Small correction: it prints 0 and doesn't print "hello" even though it
should print 1 without "hello" or an unspecified value with "hello".
> Still undefined as &x and &y + 1 are not comparable.
They cannot be compared with the relational operators ("<" etc.) but you
can compare any pointers with the equality operators ("==" and "!=").
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #26 from H.J. Lu --- Created attachment 36720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36720&action=edit A patch I am testing this patch.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #27 from Andrew Pinski --- Comment on attachment 36720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36720 A patch How does this interact with LTO where lang_hooks.decls.empty_record_p is not defined?
[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 Alexander Cherepanov changed: What|Removed |Added CC||ch3root at openwall dot com --- Comment #17 from Alexander Cherepanov --- (In reply to jos...@codesourcery.com from comment #1) > Just because two pointers print the same and have the same bit-pattern > doesn't mean they need to compare equal The standard seems to disagree. C11, 6.2.6.1p4: "Two values (other than NaNs) with the same object representation compare equal". ;-) (In reply to jos...@codesourcery.com from comment #3) > Except within a larger object, I'm not aware of any reason the cases of > two objects following or not following each other in memory must be > mutually exclusive. I guess it depends on the transitivity of the == operator. After this bug is fixed it will be possible to constuct a third pointer r from two pointer p and q such that r == p and r == q but p != q. For p and q take &x + 1 and &y as above, obtain r by stripping provenance info from p or q (e.g. by printf/scanf with %p). My impression is that the text of the standard implies interchangability of equal pointers (and hence transitivity of == ) but this area is underspecified and probably could be fixed in a way that doesn't imply transitivity of == . But is gcc ok with this? This bug and pr65752 show some complexities. OTOH == is not reflexive for double and it's ok.
[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358 --- Comment #2 from Dominique d'Humieres --- > Can you please bisect SVN revision that is responsible for these failures? The warnings are issued by dsymutil coming with Xcode 7 for darwin14 or 15. If I replace it with dsymutil coming from Xcode 6.2, the warning are gone. And the warnings are there from 4.8 up to trunk (with variations). [Book15] Downloads/tmp% gfortran-fsf-5 /opt/gcc/_clean/gcc/testsuite/gfortran.dg/alloc_comp_deep_copy_1.f03 -g -flto warning: (x86_64) could not find object file symbol for symbol ___final_alloc_comp_copy_test_T.3418.lto_priv.13 warning: (x86_64) could not find object file symbol for symbol _A.33.3739.lto_priv.7 warning: (x86_64) could not find object file symbol for symbol _A.40.3790.lto_priv.8 warning: (x86_64) could not find object file symbol for symbol _A.61.3948.lto_priv.9 warning: (x86_64) could not find object file symbol for symbol _A.68.3999.lto_priv.10 warning: (x86_64) could not find object file symbol for symbol ___def_init_alloc_comp_copy_test_T.3569.lto_priv.11 warning: (x86_64) could not find object file symbol for symbol ___vtab_alloc_comp_copy_test_T.3577.lto_priv.5 warning: (x86_64) could not find object file symbol for symbol _o3.3583.lto_priv.4 warning: (x86_64) could not find object file symbol for symbol _o4.3584.lto_priv.6 warning: (x86_64) could not find object file symbol for symbol _o1.3578.lto_priv.2 warning: (x86_64) could not find object file symbol for symbol _o2.3579.lto_priv.3 [Book15] Downloads/tmp% gfortran-fsf-4.9 /opt/gcc/_clean/gcc/testsuite/gfortran.dg/alloc_comp_deep_copy_1.f03 -g -flto warning: (x86_64) could not find object file symbol for symbol ___final_alloc_comp_copy_test_T.2359.lto_priv.13 warning: (x86_64) could not find object file symbol for symbol _A.33.2680.lto_priv.7 warning: (x86_64) could not find object file symbol for symbol _A.40.2731.lto_priv.8 warning: (x86_64) could not find object file symbol for symbol _A.61.2889.lto_priv.9 warning: (x86_64) could not find object file symbol for symbol _A.68.2940.lto_priv.10 warning: (x86_64) could not find object file symbol for symbol ___def_init_alloc_comp_copy_test_T.2510.lto_priv.11 warning: (x86_64) could not find object file symbol for symbol ___vtab_alloc_comp_copy_test_T.2518.lto_priv.5 warning: (x86_64) could not find object file symbol for symbol _o3.2524.lto_priv.4 warning: (x86_64) could not find object file symbol for symbol _o4.2525.lto_priv.6 warning: (x86_64) could not find object file symbol for symbol _o1.2519.lto_priv.2 warning: (x86_64) could not find object file symbol for symbol _o2.2520.lto_priv.3
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214
--- Comment #20 from Guille ---
(In reply to Magnus Fromreide from comment #19)
> When you say "latest openssl", do you refer to trunk or 1.0.2d? It seems
> that the problem is gone from openssl trunk due to a source reorganization
> but it seems to still be present in 1.0.2d.
Just tried building openssl-1.0.2d using 'gcc version 6.0.0 20151108' and had
no problems.
I also retested '#include \int main(){return 0;}' using latest
'gcc version 6.0.0 20151108' and it still ICEs on my system (OSX 10.9.5).
[preprocessed files are in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68351 ]
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #10 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #9) > At the current (lack of) pace I don't know when all of that will be done. > So my idea was to at least reduce the R0 problem for users by making LRA the > default in GCC 6. If we have to add the 2nd postreload temporarily, so be > it. When the other solutions become more mature and stable, we can remove > the 2nd postreload thing again. I don't object. Please go ahead. I'll report back when the regression test currently running is done.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 H.J. Lu changed: What|Removed |Added Attachment #36720|0 |1 is obsolete|| --- Comment #28 from H.J. Lu --- Created attachment 36721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36721&action=edit A patch An updated patch with middle end changes.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #29 from H.J. Lu --- (In reply to Andrew Pinski from comment #27) > Comment on attachment 36720 [details] > A patch > > How does this interact with LTO where lang_hooks.decls.empty_record_p is not > defined? We can stream out empty record info and use it to in lto_empty_record_p.
[Bug inline-asm/68095] "cc" clobber with Flag Output Operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095
--- Comment #5 from David ---
> the target code adds a cc clobber always.
Agreed. On i386, there is no way to say that an extended asm doesn't clobber
"cc", so it only serves as a comment on that specific platform.
> There is no conflict.
I believe we may be talking about two different things. From the point of view
of -da and -S, no conflicting code is generated. The output is correct and
functions as expected.
But looking at the definition of a clobber:
- "values changed by the AssemblerTemplate, beyond those listed as outputs."
- "Clobber descriptions may not in any way overlap with an input or output
operand."
It's hard to reconcile those statements with this code (which the compiler
currently accepts):
asm("bt $0, %1" : "@ccc" (vout) : "r" (vin) : "cc");
Looking at -da output, it looks like "cc" generates "clobber reg:CC", while @cc
generates "set reg:CC". It makes no sense to ever generate both, which is what
this C statement implies.
I believe the correct way to write this (which the compiler also accepts and
generates identical code) is:
asm("bt $0, %1" : "@ccc" (vout) : "r" (vin));
Silently ignoring the user's attempt to simultaneously use and clobber cc is a
logical guess about what the user really wants. But I'm saying the compiler
should instead treat that the same way it treats simultaneously clobbering and
using other things. For example: asm volatile ("" : "=a"(a) :: "eax")
generates an "impossible constraints" error.
If I have not convinced you to generate an error for the simultaneously use,
can I at least write a doc patch for this to help clarify things for users?
Something that points out that there is no way to disable "cc" for i386, and
provides a sample for using @cc?
[Bug target/68365] gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 --- Comment #2 from tprince at computer dot org --- Created attachment 36722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36722&action=edit fortran source gfortran -c lcdmod.f90 should take care of the missing .mod
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #30 from Andrew Pinski --- (In reply to H.J. Lu from comment #29) > (In reply to Andrew Pinski from comment #27) > > Comment on attachment 36720 [details] > > A patch > > > > How does this interact with LTO where lang_hooks.decls.empty_record_p is not > > defined? > > We can stream out empty record info and use it to in lto_empty_record_p. Isn't an empty record is one without any field decls?
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 --- Comment #21 from Magnus Fromreide --- Odd. I have just tried with a freshly built gcc and openssl-1.0.2d and the build still fails on line 351 (the definition of struct bn_gencb_st) On the other hand, I am running x86_64-linux, not osx.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #31 from H.J. Lu --- (In reply to Andrew Pinski from comment #30) > > Isn't an empty record is one without any field decls? I thin it is language specific.
[Bug libfortran/68115] [6 Regression] Unsatisfied symbol "__sync_lock_test_and_set_4" in file /test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgomp/../libgfortran/.libs/libgfortran.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68115 --- Comment #7 from Ian Lance Taylor --- Whatever works.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #32 from Andrew Pinski --- (In reply to H.J. Lu from comment #31) > (In reply to Andrew Pinski from comment #30) > > > > Isn't an empty record is one without any field decls? > > I thin it is language specific. How so? An record without any field decls is empty and most of the rest of the middle-end treats it that way.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 H.J. Lu changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #33 from H.J. Lu --- (In reply to Andrew Pinski from comment #32) > (In reply to H.J. Lu from comment #31) > > (In reply to Andrew Pinski from comment #30) > > > > > > Isn't an empty record is one without any field decls? > > > > I thin it is language specific. > > How so? An record without any field decls is empty and most of the rest of > the middle-end treats it that way. This is a C++ empty class with field decls from PR 68355: (gdb) cal debug_tree (type) constant 8> unit size constant 1> align 8 symtab 0 alias set -1 canonical type 0x7164e540 fields unit size align 8 symtab 0 alias set -1 canonical type 0x7164e9d8 precision 1 min max > readonly constant used public static tree_3 unsigned external nonlocal decl_3 decl_6 QI file bar.ii line 4 col 24 size unit size align 8 context template-info 0x7164c220 chain external nonlocal suppress-debug decl_4 VOID file bar.ii line 3 col 1 align 8 context result chain >> context full-name "struct integral_constant" X() has-type-conversion X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this reference_to_this chain > (gdb)
[Bug middle-end/68366] [6 Regression] sdbout.c build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68366 --- Comment #1 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Mon Nov 16 02:28:15 2015 New Revision: 230402 URL: https://gcc.gnu.org/viewcvs?rev=230402&root=gcc&view=rev Log: PR 68366 - include emit-rtl.h in sdbout.c Some of the pa target macros rely on macros in emit-rtl.h and sdbout.c uses some of those macros, which means that sdbout.c needs to include emit-rtl.h. gcc/ChangeLog: 2015-11-15 Trevor Saunders PR middle-end/68366 * sdbout.c: Include emit-rtl.h and function.h. Modified: trunk/gcc/ChangeLog trunk/gcc/sdbout.c
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #34 from Andrew Pinski --- (In reply to H.J. Lu from comment #33) > (In reply to Andrew Pinski from comment #32) > > (In reply to H.J. Lu from comment #31) > > > (In reply to Andrew Pinski from comment #30) > > > > > > > > Isn't an empty record is one without any field decls? > > > > > > I thin it is language specific. > > > > How so? An record without any field decls is empty and most of the rest of > > the middle-end treats it that way. > > This is a C++ empty class with field decls from PR 68355: > > (gdb) cal debug_tree (type) > size bitsizetype> constant 8> > unit size sizetype> constant 1> > align 8 symtab 0 alias set -1 canonical type 0x7164e540 > fields type size unit size > align 8 symtab 0 alias set -1 canonical type 0x7164e9d8 > precision 1 min max 0x71506240 1>> > readonly constant used public static tree_3 unsigned external > nonlocal decl_3 decl_6 QI file bar.ii line 4 col 24 size 0x714e5f90 8> unit size > align 8 context > template-info 0x7164c220 > chain 0x7164e930 integral_constant> > external nonlocal suppress-debug decl_4 VOID file bar.ii line 3 > col 1 > align 8 context > result > chain >> context > > full-name "struct integral_constant" > X() has-type-conversion X(constX&) this=(X&) n_parents=0 use_template=1 > interface-unknown > pointer_to_this reference_to_this > chain integral_constant>> > (gdb) So no FIELD_DECL as part of fields; only var or type or method_decl?
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 --- Comment #22 from Guille --- For what it's worth, I just checked again openssl-1.0.2d builds fine with 'gcc 6.0.0 20151108' on OSX 10.9.5. Checked it is running the right gcc (both with and without '-g'), configured with 'darwin-i386-cc' and 'darwin64-x86_64-cc'. I wasn't able to break it. (In reply to Magnus Fromreide from comment #21) > Odd. I have just tried with a freshly built gcc and openssl-1.0.2d and the > build still fails on line 351 (the definition of struct bn_gencb_st) > On the other hand, I am running x86_64-linux, not osx.
[Bug c/68369] New: Unnecessary copying esp to ebp with regparm={1,2,3} on x86 at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68369
Bug ID: 68369
Summary: Unnecessary copying esp to ebp with regparm={1,2,3} on
x86 at -Os
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: technosaurus at yahoo dot com
Target Milestone: ---
This occurs on all versions tested for this simple test case:
> int nop(int x){return x;}
with gcc 5.2+ @ -O1,-O2 and -O3 this correctly compiles to:
> nop(int):
> rep ret
however with -Os, it sub-optimally compiles to:
> nop(int):
> pushl %ebp
> movl%esp, %ebp
> popl%ebp
> ret
At -O0, ebp is actually used which may hint why -Os doesn't pick it up
> nop(int):
> pushl %ebp
> movl%esp, %ebp
> subl$4, %esp
> movl%eax, -4(%ebp)
> movl-4(%ebp), %eax
> leave
> ret
Backtracking other optimization levels, the same behavior was fixed for -O1,
-O2 and -O3 somewhere between gcc-4.5.3 and 4.6.4 but remains suboptimal for
-Os up to 5.2.0
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #35 from H.J. Lu ---
(In reply to Andrew Pinski from comment #34)
>
> So no FIELD_DECL as part of fields; only var or type or method_decl?
struct dummy { };
struct true_type { struct dummy i; };
gave:
(gdb) cal debug_tree (type)
constant 8>
unit size constant 1>
align 8 symtab 0 alias set -1 canonical type 0x71647dc8
fields unit size
align 8 symtab 0 alias set -1 canonical type 0x71647bd0 fields
context
full-name "struct dummy"
X() X(constX&) this=(X&) n_parents=0 use_template=0
interface-unknown
pointer_to_this reference_to_this
chain >
nonlocal decl_3 QI file z.ii line 2 col 33 size unit size
align 8 offset_align 128
offset
bit offset context
chain
nonlocal decl_4 VOID file z.ii line 2 col 18
align 1 context result
>> context
full-name "struct true_type"
X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
pointer_to_this reference_to_this
chain >
(gdb)
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 H.J. Lu changed: What|Removed |Added Attachment #36721|0 |1 is obsolete|| --- Comment #36 from H.J. Lu --- Created attachment 36723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36723&action=edit An updated patch to use is_really_empty_class I am testing this.
[Bug jit/68370] New: Pointer arithmetic in libgccjit seems to require an extra cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370
Bug ID: 68370
Summary: Pointer arithmetic in libgccjit seems to require an
extra cast
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Hi,
maybe I'm doing something wrong, but libgccjit rejects an assignment of pointer
arithmetic where the types (according to the diagnostic) are OK.
This is not a blocker as it can be worked around using an explicit cast.
I am using GCC 5.2.0.
I have a function "int test(const char* text)" with a single block.
gcc_jit_type *int_type = gcc_jit_context_get_type (ctx, GCC_JIT_TYPE_INT);
gcc_jit_type *const_char_ptr_type =
gcc_jit_context_get_type (ctx, GCC_JIT_TYPE_CONST_CHAR_PTR);
// param: const char* text;
gcc_jit_param *param_text =
gcc_jit_context_new_param (ctx, /* loc */ NULL, const_char_ptr_type,
"text");
gcc_jit_rvalue *rval_text = gcc_jit_param_as_rvalue (param_text);
// int test(const char* text);
gcc_jit_param *params[] = { param_text };
gcc_jit_function *test_fun =
gcc_jit_context_new_function (ctx, /* loc */ NULL,
GCC_JIT_FUNCTION_EXPORTED, int_type, "test",
1, params, /* is_variadic */ 0);
gcc_jit_block *block = gcc_jit_function_new_block (test_fun, "test-block");
and then I want to compute
text++;
According to the documentation this has to be done like this.
text = &text[1];
But if I write
// text = &text[1]; // does not work
gcc_jit_block_add_assignment (block, /* loc */ NULL,
gcc_jit_param_as_lvalue (param_text),
gcc_jit_lvalue_get_address(
gcc_jit_context_new_array_access(ctx, /* loc */ NULL,
rval_text,
gcc_jit_context_one (ctx, int_type)),
/* loc */ NULL));
libgccjit rejects it with
libgccjit.so: error: gcc_jit_block_add_assignment: mismatching types:
assignment to text (type: const char *) from &text[(int)1] (type: const char *)
This can be worked around using a cast:
gcc_jit_block_add_assignment (block, /* loc */ NULL,
gcc_jit_param_as_lvalue (param_text),
gcc_jit_context_new_cast (ctx, /* loc */ NULL,
gcc_jit_lvalue_get_address(
gcc_jit_context_new_array_access(ctx, /* loc */ NULL,
rval_text,
gcc_jit_context_one (ctx, int_type)),
/* loc */ NULL),
const_char_type));
Kind regards,
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #37 from Andrew Pinski ---
(In reply to H.J. Lu from comment #35)
> (In reply to Andrew Pinski from comment #34)
> >
> > So no FIELD_DECL as part of fields; only var or type or method_decl?
>
> struct dummy { };
> struct true_type { struct dummy i; };
This is two empty structs. The same is true even in GNU C. So a struct which
contains no field decls or field decls which is an empty struct is also an
empty struct.
[Bug jit/68370] Pointer arithmetic in libgccjit seems to require an extra cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370 --- Comment #1 from Andrew Pinski --- // text++; Can't this be computed as: text = text POINTER_PLUS 1; ?
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-16 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- Started with the delayed folding merge: r230365.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #38 from H.J. Lu --- Created attachment 36724 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36724&action=edit An updated patch to add empty_record_p I am testing it now.
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 --- Comment #23 from Magnus Fromreide --- One more question - you are using the command g++ -g file_that_include_ssl_h.cpp right? Building it as C works for me as well.
[Bug c/68371] New: complex number will be initialized a NAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68371
Bug ID: 68371
Summary: complex number will be initialized a NAN
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wuyi at inspur dot com
Target Milestone: ---
while the imaginary part has a NAN or INF,it will affect the real part value;so
the complex number is not correct.
1 #include
2 #include
3 #include
4 #include
5
6
7 int main(){
8 // double _Imaginary i = __imag__ I;
9 // printf("I=%g\n",i);
10
11 double complex a,b,c,d;
12
13 a = NAN + 5.0*I;
14 b = 5.0 + NAN*I;
15 c = INFINITY + 5.0*I;
16 d = 5.0 + INFINITY*I;
17 printf("real = %g imag = %g\n",__real__ a,__imag__ a);
18 printf("real = %g imag = %g\n",__real__ b,__imag__ b);
19 printf("real = %g imag = %g\n",__real__ c,__imag__ c);
20 printf("real = %g imag = %g\n",__real__ d,__imag__ d);
21
22 return 0;
23 }
c99 -lm test.c
./a.out
real = nan imag = 5
real = nan imag = nan
real = inf imag = 5
real = nan imag = inf
