[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71854 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-13 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE at -O3 in both 32-bit |[7 Regression] ICE at -O3 |and 64-bit modes on |in both 32-bit and 64-bit |x86_64-linux-gnu|modes on x86_64-linux-gnu |(verify_gimple failed) |(verify_gimple failed) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r236440.
[Bug c/71852] add warning for conditions that can never be true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71852 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- We do have a simple bitmask propagation pass - ccp. The question is if it isn't too late for such warning, as in if the preceeding optimizations don't change the code enough (even for ccp1) that the warning would have too many false positives.
[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71854 Jakub Jelinek changed: What|Removed |Added CC||ienkovich at gcc dot gnu.org Version|unknown |7.0 --- Comment #2 from Jakub Jelinek --- This is the masked case for SLP vectorization in vectorizable_comparison, wonder if for the slp_node case where for masked we don't get a type compatible with vec_cmp_type we just shouldn't add a NE_EXPR comparison with zero instead of using the non-vect-boolean argument directly (which is invalid IL).
[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574 --- Comment #4 from rguenther at suse dot de --- On Tue, 12 Jul 2016, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574 > > --- Comment #3 from Marc Glisse --- > Makes sense, I don't know why I didn't add divisions in the original patch. > *_MOD_EXPR, shifts and rotates should work as well with 0 on the left, max > with > INT_MAX, etc, I was quite minimalist there. > > Of course, if I had gone with the simpler approach of folding the operation > after replacement (here 0 / 10) and comparing that with the PHI argument, we > wouldn't need the neutral/absorbing logic at all :-( Yeah, but folding would happily create undefined behavior from, say, if (x != INT_MIN) x = x * -1; as folding folds INT_MIN * -1 to INT_MIN (ok, maybe with TREE_OVERFLOW set, but I'm not sure we want to rely on that). Re-testing with mod and shift/rotates added.
[Bug fortran/58157] ICE on character function with len given by a PURE function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58157 --- Comment #3 from Davide Cesari --- Update: I tested with the latest version available on a fresh Fedora24, gcc version 6.1.1 20160621, and the bug is still the same: internal compiler error: Segmentation fault Davide
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #11 from Richard Biener --- Author: rguenth Date: Wed Jul 13 08:03:04 2016 New Revision: 238287 URL: https://gcc.gnu.org/viewcvs?rev=238287&root=gcc&view=rev Log: 2016-07-13 Richard Biener PR middle-end/71104 * gimplify.c (gimplify_modify_expr): Gimplify the RHS before gimplifying the LHS. Make sure to gimplify a returning twice call LHS without using SSA names. * gcc.dg/pr71104-1.c: New testcase. * gcc.dg/pr71104-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr71104-1.c trunk/gcc/testsuite/gcc.dg/pr71104-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Finally fixed.
[Bug tree-optimization/71503] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "gen_phi_arg_condition"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71503 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #4 from amker at gcc dot gnu.org --- The issue has been there before the change, latent because we only handle multiple args phi node for loops with simd pragma then. I will have a look.
[Bug tree-optimization/71736] [7 Regression] ICE in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71736 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Richard Biener --- dup. *** This bug has been marked as a duplicate of bug 71104 ***
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 Richard Biener changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #13 from Richard Biener --- *** Bug 71736 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/11832] Optimization of common stores in switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11832
--- Comment #11 from Richard Biener ---
Note the testcase is flawed because c might point to b and thus the stores to
c[b] might clobber b itself. Similar c might point to c itself and thus
clobber the pointer value. This causes us to re-load both b and c after
each store.
Making b local and c a parameter avoids these issues:
int a, e;
void foo(unsigned char *c)
{
int d = 13;
int b = -1;
switch (e) {
case 1:
b++; c[b] = (unsigned char)d;
break;
case 2:
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
break;
case 3:
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
break;
default:
a = 1;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
b++; c[b] = (unsigned char)d;
}
}
I have a patch to do some store merging during SSA code sinking but it doesn't
handle this case because the 1) the stores are ordered in the wrong way,
2) the CFG is not in proper form (I only handle common stores appearing in
all predecessors)
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #1 from Richard Biener --- seeding from the current time sounds like a bad idea from a security perspective. why not __RANDOM__ or __SECURE_RANDOM__?
[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574 --- Comment #5 from Marc Glisse --- (In reply to rguent...@suse.de from comment #4) > Yeah, but folding would happily create undefined behavior from, say, > > if (x != INT_MIN) >x = x * -1; > > as folding folds INT_MIN * -1 to INT_MIN (ok, maybe with TREE_OVERFLOW > set, but I'm not sure we want to rely on that). The C++ front-end already relies on constant folding detecting undefined behavior, so at least this case seems fine. But there may indeed be symbolic cases where we would simplify the operation assuming that some undefined behavior doesn't occur, while that is precisely what the condition was protecting against... (though I have a hard time coming up with an example that works with a single stmt) So fold may not be quite the right interface. Maybe we should mark in some way the transformations that assume a restricted range, so we can generate a limited version of fold where the reverse transformation is safe. Not something for right now anyway.
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Any kind of such code goes strongly against build reproduceability,
-fcompare-debug etc., so not sure it would be really appreciated, it is a
direction against various changes done in gcc lately.
I think if you need something like that just pass
-DRANDOM=`dd if=/dev/random bs=8 count=1 2>/dev/null | md5sum | awk '{print
$1}'`
or something similar.
[Bug ipa/71633] [7 regression][CHKP] internal compiler error: in inline_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71633 --- Comment #2 from Ilya Enkovich --- Author: ienkovich Date: Wed Jul 13 11:02:15 2016 New Revision: 238290 URL: https://gcc.gnu.org/viewcvs?rev=238290&root=gcc&view=rev Log: gcc/ PR ipa/71633 * ipa-inline-transform.c (inline_call): Support instrumented thunks. gcc/testsuite/ PR ipa/71633 * g++.dg/pr71633.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr71633.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-transform.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/71633] [7 regression][CHKP] internal compiler error: in inline_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71633 Ilya Enkovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ilya Enkovich --- Fixed
[Bug c/71855] New: duplicate unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855 Bug ID: 71855 Summary: duplicate unspecified_parameters DIE in DWARF for functions with variable arguments Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- I was looking at the DWARF generated by GCC 6.1 for M4 and it emits two DIEs for unspecified parameters. Before Dodji added special code to ignore this, it confused libabigail and may confuse other DWARF consumers. [ 1a33]subprogram external (flag_present) name (strp) "m4_error" decl_file(data1) 1 decl_line(data1) 94 prototyped (flag_present) low_pc (addr) 0x00402d10 high_pc (data8) 194 (0x00402dd2) frame_base (exprloc) [ 0] call_frame_cfa GNU_all_call_sites (flag_present) sibling (ref4) [ 1aab] [ 1a50] formal_parameter name (strp) "status" decl_file(data1) 1 decl_line(data1) 94 type (ref4) [58] location (sec_offset) location list [ 78e] [ 1a5f] formal_parameter name (strp) "errnum" decl_file(data1) 1 decl_line(data1) 94 type (ref4) [58] location (sec_offset) location list [ 7c7] [ 1a6e] formal_parameter name (strp) "format" decl_file(data1) 1 decl_line(data1) 94 type (ref4) [d8] location (sec_offset) location list [ 800] [ 1a7d] unspecified_parameters [ 1a7e] variable name (strp) "args" decl_file(data1) 1 decl_line(data1) 96 type (ref4) [ 410] location (exprloc) [ 0] fbreg -216 [ 1a8d] unspecified_parameters [ 1a8e] GNU_call_site low_pc (addr) 0x00402dad abstract_origin (ref4) [ 1fba] [ 1a9b]GNU_call_site_parameter location (exprloc) [ 0] reg8 GNU_call_site_value (exprloc) [ 0] GNU_entry_value: [ 0] reg1 [ 1aa2]GNU_call_site_parameter location (exprloc) [ 0] reg9 GNU_call_site_value (exprloc) [ 0] fbreg -216 See 1a7d 1a8d. This was generated from compiling m4 from ftp://ftp.gnu.org/gnu/m4/m4-1.4.17.tar.gz with GCC 6.1 I will work on making a smaller reproducer.
[Bug ipa/71624] [6 regression][CHKP] internal compiler error: in duplicate_thunk_for_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71624 --- Comment #4 from Ilya Enkovich --- Author: ienkovich Date: Wed Jul 13 12:19:44 2016 New Revision: 238295 URL: https://gcc.gnu.org/viewcvs?rev=238295&root=gcc&view=rev Log: gcc/ Backport from mainline r238086. 2016-07-07 Ilya Enkovich PR ipa/71624 * ipa-inline-analysis.c (compute_inline_parameters): Set local.can_change_signature to false for intrumentation thunk callees. gcc/testsuite/ Backport from mainline r238086. 2016-07-07 Ilya Enkovich PR ipa/71624 * g++.dg/pr71624.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/pr71624.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/ipa-inline-analysis.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug ipa/71624] [6 regression][CHKP] internal compiler error: in duplicate_thunk_for_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71624 Ilya Enkovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ilya Enkovich --- Fixed
[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-07-13 Assignee|unassigned at gcc dot gnu.org |nickc at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Nick Clifton --- Created attachment 38884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38884&action=edit Proposed patch Hi, Thanks for the test case. With that I was able to reproduce the problem and I think that I have a patch that can fix it. Please could you test it for yourself and let me know if it works. (I have uploaded two versions, one for the current FSF binutils mainline development sources, and one for the 2.25.1 release sources). Cheers Nick
[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 --- Comment #10 from Nick Clifton --- Created attachment 38885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38885&action=edit Proposed patch
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Any kind of such code goes strongly against build reproduceability,
> -fcompare-debug etc., so not sure it would be really appreciated, it is a
> direction against various changes done in gcc lately.
> I think if you need something like that just pass
> -DRANDOM=`dd if=/dev/random bs=8 count=1 2>/dev/null | md5sum | awk '{print
> $1}'`
> or something similar.
I think he wants to have a new random value each time __RANDOM is "evaluated"
(during C++ template instantiation - thus a preprocessor macro isn't really
apppropriate).
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #4 from Jakub Jelinek --- Then command line macro + __COUNTER__ ?
[Bug c/71855] duplicate unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855 --- Comment #1 from Ben Woodard --- I just discovered (by mistake) that the problem does not seem to happen with GCC 4.4.7.
[Bug libstdc++/71856] New: _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 Bug ID: 71856 Summary: _GLIBCXX_DEBUG-mode breaks GNU parallel extension Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: michael.hamann at kit dot edu Target Milestone: --- When _GLIBCXX_DEBUG is defined, the recently introduced macro _GLIBCXX_ASSERTIONS (see #56109) is defined as empty (see https://github.com/gcc-mirror/gcc/blob/55174bb97660bbd9c27262bc48b6da88a1b4a18f/libstdc%2B%2B-v3/include/bits/c%2B%2Bconfig#L415). Unfortunately, the new macro (_GLIBCXX_ASSERTIONS) was already in use in the GNU parallel extension where it is always defined (see https://github.com/gcc-mirror/gcc/blob/edd716b6b1caa1a5cb320a8cd7f626f30198e098/libstdc%2B%2B-v3/include/parallel/compiletime_settings.h#L58). There almost all checks for it use a simple #if (without "defined"), see e.g. https://github.com/gcc-mirror/gcc/blob/edd716b6b1caa1a5cb320a8cd7f626f30198e098/libstdc%2B%2B-v3/include/parallel/balanced_quicksort.h#L54. When enabling _GLIBCXX_DEBUG, _GLIBCXX_ASSERTIONS is defined as empty, which makes it impossible to compile code that uses the GNU parallel extension (error: #if with no expression). Further, the define of _GLIBCXX_ASSERTIONS to 0 in the GNU parallel extension might enable assertions in other parts of the standard library unintentionally. I encountered the bug in GCC 6.1.1, but the affected code seems to be unchanged in the current trunk version (all code links point to the trunk version).
[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 --- Comment #1 from Jonathan Wakely --- You can't mix Debug Mode and Parallel Mode anyway. With previous versions you get In file included from /usr/include/c++/5.3.1/utility:68:0, from /usr/include/c++/5.3.1/algorithm:60, from par.cc:1: /usr/include/c++/5.3.1/x86_64-redhat-linux/bits/c++config.h:2092:4: error: #error illegal use of multiple inlined namespaces # error illegal use of multiple inlined namespaces ^ Now you get that followed by a cascade of other errors, which should be fixed, but you'll never be able to mix them.
[Bug target/71652] [4.9/5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652
--- Comment #4 from Martin Liška ---
Thank you very much Jakub with the suggested hint.
I applied basically what you suggested and I'm wondering whether target macro
can really produce insane options that would eventually cause an ICE or another
misleading error?
As I've been playing with x86 target options I came to multiple question
(probably something we should fix):
1)
https://gcc.gnu.org/onlinedocs/gcc/x86-Function-Attributes.html#x86-Function-Attributes
section does no document all accepted values of target attribute:
fma
avx512f
avx512er
avx512cd
avx512pf
avx512dq
avx512bw
avx512vl
avx512ifma
avx512vbmi
3dnow
bmi
bmi2
lzcnt
hle
fxsr
rdseed
prfchw
adx
tbm
sha
fsgsbase
rdrnd
f16c
rtm
xsave
xsaveopt
prefetchwt1
clflushopt
xsavec
xsaves
clwb
pcommit
mwaitx
Suggestion: let's document them
2) on the other hand, ‘fused-madd’ and ‘no-fused-madd’ are document, but we
reject them:
tc.cc:2:33: error: attribute(target("fused-madd")) is unknown
probably because of:
./xg++ -B. tc.cc -mfused-madd
xg++: warning: ‘-mfused-madd’ is deprecated; use ‘-ffp-contract=’ instead
Suggestion: remove the option from documentation
3) There are ISA options that are not accepted:
3dnowa
movbe
crc32
mpx
clzero
pku
Suggestion: accept them?
[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 --- Comment #2 from Michael Hamann --- This is not about activating parallel mode, this is about using individual parallel algorithms by directly including e.g. and using the namespace __gnu_parallel explicitly. There I do not get the error you mention. Is this not supported, too?
[Bug target/71652] [4.9/5/6/7 Regression] ICE in in ix86_target_macros_internal, at config/i386/i386-c.c:187
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71652 --- Comment #5 from Martin Liška --- Created attachment 38886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38886&action=edit Candidate patch
[Bug tree-optimization/24568] [meta-bug] Missed optimization: trivialization of silly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568 Bug 24568 depends on bug 24574, which changed state. Bug 24574 Summary: a!=0?a/10:0 is not reduced to a/10 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/24574] a!=0?a/10:0 is not reduced to a/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24574 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Jul 13 13:57:05 2016 New Revision: 238299 URL: https://gcc.gnu.org/viewcvs?rev=238299&root=gcc&view=rev Log: 2016-07-13 Richard Biener PR tree-optimization/24574 * tree-ssa-phiopt.c (absorbing_element_p): Pass in argument position and add shift, rotate, divison and modulo support for left zero. (value_replacement): Pass in argument position to absorbing_element_p. * gcc.dg/pr24574.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr24574.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiopt.c
[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-13 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Ah I see. A testcase would have helped clarify that, as requested by https://gcc.gnu.org/bugs
[Bug tree-optimization/71490] [7 regression] gcc.dg/tree-ssa/slsr-8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71490 --- Comment #5 from Martin Liška --- The r237185 revision really caused that one slsr opportunity is gone, however there's still one remaining (-fno-tree-slsr vs -ftree-slsr) show: : - a2_15 = s_11(D) * 4; - _4 = (long unsigned int) a2_15; - _5 = _4 * 4; - _6 = -_5; - x2_16 = c_13(D) + _6; + x2_16 = x1_14 + _3; goto ; I'm going to send patch to ML.
[Bug tree-optimization/71857] New: [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71857 Bug ID: 71857 Summary: [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- It's caused by my commit r238252.
[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71857 --- Comment #1 from Martin Liška --- Created attachment 38887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38887&action=edit IVOPTS dump before the commit
[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71857 --- Comment #2 from Martin Liška --- Created attachment 3 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3&action=edit IVOPTS dump after the commit
[Bug tree-optimization/71857] [7 Regression] gcc.dg/tree-ssa/ivopt_mult_4.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71857 Martin Liška changed: What|Removed |Added CC||amker.cheng at gmail dot com --- Comment #3 from Martin Liška --- The difference is caused by increased average number of loop iterations (from 5 to 10), which caused a different selection of candidates: before: Selected IV set for loop 1 at /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c:19, 5 avg niters, 0 expressions, 2 IVs: Candidate 7: Var befor: p2_27 Var after: p2_14 Incr POS: orig biv IV struct: Type: long int * Base: p2_11(D) + 8 Step: 8 Object: (void *) p2_11(D) Biv:N Overflowness wrto loop niter: Overflow Candidate 9: Var befor: i_28 Var after: i_15 Incr POS: orig biv IV struct: Type: long unsigned int Base: 16 Step: 16 Biv:N Overflowness wrto loop niter: No-overflow after: Selected IV set for loop 1 at /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/ivopt_mult_4.c:19, 10 avg niters, 0 expressions, 2 IVs: Candidate 7: Var befor: p2_27 Var after: p2_14 Incr POS: orig biv IV struct: Type: long int * Base: p2_11(D) + 8 Step: 8 Object: (void *) p2_11(D) Biv:N Overflowness wrto loop niter: Overflow Candidate 10: Var befor: ivtmp.11_21 Var after: ivtmp.11_29 Incr POS: before exit test IV struct: Type: unsigned long Base: (unsigned long) (p_16(D) + 128) Step: 128 Object: (void *) p_16(D) Biv:N Overflowness wrto loop niter: Overflow Replacing exit test: if (_22 > i_28) Should I just amend the dump scan to cover the 'Replacing exit test' ?
[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 --- Comment #21 from Boris Kolpackov --- Speaking of possible fixes, I had this crazy idea, not sure if it is technically possible though: what if libstdc++ throws some custom exception that derives from both version of ios::failure? This way both old and new ABI users will be able to catch it via the respective bases.
[Bug testsuite/71489] [7 regression] gcc.dg/tree-ssa/attr-hotcold-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71489 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- After r237605, the issues should be fixed? I can't reproduce it on x86_64-linux.
[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71623 --- Comment #8 from vehre at gcc dot gnu.org --- Author: vehre Date: Wed Jul 13 16:09:57 2016 New Revision: 238304 URL: https://gcc.gnu.org/viewcvs?rev=238304&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-07-13 Andre Vehreschild Backport from trunk: PR fortran/71623 * trans-stmt.c (gfc_trans_allocate): Add code of pre block of typespec in allocate to parent block. gcc/testsuite/ChangeLog: 2016-07-13 Andre Vehreschild Backport from trunk: PR fortran/71623 * gfortran.dg/deferred_character_17.f90: New test. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/deferred_character_17.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/trans-stmt.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c/71858] New: Surprising suggestions for misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71858
Bug ID: 71858
Summary: Surprising suggestions for misspellings
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
(from email)
$ cat /tmp/a.c
int main(int argc, char **argv)
{
return bar();
}
$ ./xgcc -B. /tmp/a.c
/tmp/a.c: In function ‘main’:
/tmp/a.c:3:10: warning: implicit declaration of function ‘bar’; did you mean
‘carg’? [-Wimplicit-function-declaration]
return bar();
^~~
carg
Which is a bit misleading as I do not include any header file. Looks it finds a
builtin:
(gdb) p debug_tree(m_best_candidate)
QI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0x768adc78
arg-types
chain >>>
readonly nothrow public external built-in decl_6 QI file
line 0 col 0
align 8 built-in BUILT_IN_NORMAL:BUILT_IN_CARG attributes >>
Well, I would expect it should consider __builtin_carg, but not carg.
I'm inclined to agree; I'll see if I can filter this better.
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #5 from Daniel Gutson --- The idea is that the macro expands always to the same value. The final usage of this facility should not be of any matter to gcc, it will be just another program. This macro would change break reproduceability as much as __TIME__ does. IOW, just another predefined macro that will be used in the program. Anecdotically it will be used for randomization seeding. Richard, what would __RANDOM__ expand to? Please see that I try to maintain separated the use case from the functionality, a functionality that is already present (getting time during preprocessing but with more precision).
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851
--- Comment #6 from Daniel Gutson ---
(In reply to Richard Biener from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Any kind of such code goes strongly against build reproduceability,
> > -fcompare-debug etc., so not sure it would be really appreciated, it is a
> > direction against various changes done in gcc lately.
> > I think if you need something like that just pass
> > -DRANDOM=`dd if=/dev/random bs=8 count=1 2>/dev/null | md5sum | awk '{print
> > $1}'`
> > or something similar.
>
> I think he wants to have a new random value each time __RANDOM is "evaluated"
> (during C++ template instantiation - thus a preprocessor macro isn't really
> apppropriate).
Actually I don't. As I mention in my last comment, the macro should have the
same value during all compilation. I already wrote a compile-time PRNG (and
another layer that uses it), but please don't get biased by this fact.
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #7 from Jakub Jelinek --- (In reply to Daniel Gutson from comment #5) > This macro would change break reproduceability as much as __TIME__ does. __TIME__ is now being warned on if requested (-Wdate-time), and can be changed through environment variables - SOURCE_DATE_EPOCH env var - and for -fcompare-debug SOURCE_DATE_EPOCH is set by the driver for both invocations the same. So, as you can see, there is a strong shift away from __DATE__/__TIME__.
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > I have not done a bootstrap/test yet but I can do it on a machine which has > LSE support in a few minutes. Note this patch causes many failures but none in gcc testing, only in libgomp testing and in glibc itself.
[Bug preprocessor/71851] Get more time granularity at preprocessing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71851 --- Comment #8 from Daniel Gutson --- (In reply to Jakub Jelinek from comment #7) > (In reply to Daniel Gutson from comment #5) > > This macro would change break reproduceability as much as __TIME__ does. > > __TIME__ is now being warned on if requested (-Wdate-time), and can be > changed > through environment variables - SOURCE_DATE_EPOCH env var - and for > -fcompare-debug SOURCE_DATE_EPOCH is set by the driver for both invocations > the same. > So, as you can see, there is a strong shift away from __DATE__/__TIME__. OK, granted. I complain that build reproduceability is a specific requirement for a particular audience of users; other users may need just the opposite and IMVHO I think have the same right to claim it. This is of course a dead end discussion we won't have here. We will implement this as a cpp plugin, so feel free to close the issue.
[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 --- Comment #4 from Michael Hamann --- Created attachment 38889 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38889&action=edit Test case, try compiling with g++ -D_GLIBCXX_DEBUG testcase.cpp Sorry for not including a test case, I thought from the description and the provided links the problem was clear enough but of course I should have known better. I've attached a minimal test case.
[Bug libstdc++/71856] _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Wed Jul 13 17:22:57 2016 New Revision: 238307 URL: https://gcc.gnu.org/viewcvs?rev=238307&root=gcc&view=rev Log: libstdc++/71856 Define _GLIBCXX_PARALLEL_ASSERTIONS PR libstdc++/71856 * include/bits/c++config (_GLIBCXX_ASSERTIONS): Define to 1 not empty. * include/parallel/compiletime_settings.h (_GLIBCXX_ASSERTIONS): Rename to _GLIBCXX_PARALLEL_ASSERTIONS and make default value depend on _GLIBCXX_ASSERTIONS. * include/parallel/balanced_quicksort.h: Rename _GLIBCXX_ASSERTIONS. Include for sleep. * include/parallel/losertree.h: Rename _GLIBCXX_ASSERTIONS. * include/parallel/merge.h: Likewise. * include/parallel/multiway_merge.h: Likewise. * include/parallel/partition.h: Likewise. * include/parallel/queue.h: Likewise. * include/parallel/sort.h: Likewise. * testsuite/25_algorithms/headers/algorithm/ parallel_algorithm_assert.cc: New. Added: trunk/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/include/parallel/balanced_quicksort.h trunk/libstdc++-v3/include/parallel/compiletime_settings.h trunk/libstdc++-v3/include/parallel/losertree.h trunk/libstdc++-v3/include/parallel/merge.h trunk/libstdc++-v3/include/parallel/multiway_merge.h trunk/libstdc++-v3/include/parallel/partition.h trunk/libstdc++-v3/include/parallel/queue.h trunk/libstdc++-v3/include/parallel/sort.h
[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 Jonathan Wakely changed: What|Removed |Added Known to work||5.3.0 Target Milestone|--- |6.2 Summary|_GLIBCXX_DEBUG-mode breaks |[6/7 Regression] |GNU parallel extension |_GLIBCXX_DEBUG-mode breaks ||GNU parallel extension --- Comment #6 from Jonathan Wakely --- (In reply to Michael Hamann from comment #4) > Sorry for not including a test case, I thought from the description and the > provided links the problem was clear enough but of course I should have > known better. I've attached a minimal test case. I'm better at understanding C++ than words sometimes :-) I've changed to do: // Debug Mode implies checking assertions. #ifdef _GLIBCXX_DEBUG # define _GLIBCXX_ASSERTIONS 1 #endif Which solves the missing expression with "#if _GLIBCXX_ASSERTIONS" I've also changed to use _GLIBCXX_PARALLEL_ASSERTIONS instead, so those headers won't unintentionally enable assertions in the rest of the library. I'll make the same change on the gcc-6 branch shortly.
[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71623 --- Comment #9 from vehre at gcc dot gnu.org --- Author: vehre Date: Wed Jul 13 17:30:58 2016 New Revision: 238308 URL: https://gcc.gnu.org/viewcvs?rev=238308&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-07-13 Andre Vehreschild Backport from trunk: PR fortran/71623 * trans-stmt.c (gfc_trans_allocate): Add code of pre block of typespec in allocate to parent block. gcc/testsuite/ChangeLog: 2016-07-13 Andre Vehreschild Backport from trunk: PR fortran/71623 * gfortran.dg/deferred_character_18.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_18.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-stmt.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/71859] New: ICE on same variable/subroutine name (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71859 Bug ID: 71859 Summary: ICE on same variable/subroutine name (verify_gimple failed) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- When using the same name for a variable and a subroutine (invalid), experimental (--enable-checking=yes) versions 7, 6 and maybe older ones (not tested) give an ICE. No ICE for release versions 4.9, 5, 6, 7. $ cat z1.f90 program p call s(1) x = abs(s) end subroutine s(n) print *, n end $ gfortran-6 -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90 $ a.out 1 $ gfortran-7-20160710 z1.f90 z1.f90:1:0: program p Error: invalid types in conversion to floating point real(kind=8) void (*) (integer(kind=4) & restrict) x = (real(kind=8)) s; z1.f90:1:0: internal compiler error: verify_gimple failed 0xc48e8d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:4879 0x9c9ec2 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:11710 0x9ca256 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:11798 0x8360b7 cgraph_node::analyze() ../../gcc/cgraphunit.c:625 0x839443 analyze_functions ../../gcc/cgraphunit.c:1086 0x83a128 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2543
[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71859 --- Comment #1 from Gerhard Steinmetz --- Somehow detected when being a bit more explicit : $ cat z3.f90 program p implicit none real :: s = 1.0 real :: x call s(1) x = abs(s) print *, x end subroutine s(n) implicit none integer :: n print *, n end $ gfortran-7-20160710 z3.f90 z3.f90:3:12: real :: s = 1.0 1 Error: 's' at (1) is not a VALUE z3.f90:3:12: real :: s = 1.0 1 z3.f90:5:12: call s(1) 2 Error: 's' at (1) has a type, which is not consistent with the CALL at (2) z3.f90:6:11: x = abs(s) 1 Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type
[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71859 --- Comment #2 from Gerhard Steinmetz --- For completeness another ICE, only with dedicated option -ff2c. $ gfortran-6 -ff2c z1.f90 z1.f90:2:0: call s(1) internal compiler error: in fold_convert_loc, at fold-const.c:2292 $ gfortran-7-20160710 -ff2c z1.f90 z1.f90:2:0: call s(1) internal compiler error: in fold_convert_loc, at fold-const.c:2289 0x943323 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2289 0x758a7f gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:6072 0x798674 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:407 0x71c28a trans_code ../../gcc/fortran/trans.c:1755 0x74ac88 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6171 0x6d6860 translate_all_program_units ../../gcc/fortran/parse.c:5914 0x6d6860 gfc_parse_file() ../../gcc/fortran/parse.c:6120 0x718d12 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/71860] New: ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 Bug ID: 71860 Summary: ICE on pointing to null(mold), verify_gimple failed Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- ICE with experimental (--enable-checking=yes) versions 7, 6, and maybe older. $ cat z1.f90 program p class(*), pointer :: z z => null(z) end $ gfortran-6 -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1.f90 $ a.out $ gfortran-7 z1.f90# release $ a.out $ gfortran-7-20160710 z1.f90 # experimental z1.f90:1:0: program p Error: conversion of register to a different size VIEW_CONVERT_EXPR(_1); z = VIEW_CONVERT_EXPR(_1); z1.f90:1:0: internal compiler error: verify_gimple failed 0xc48e8d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:4879 0x9c9ec2 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:11710 0x9ca256 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:11798 0x8360b7 cgraph_node::analyze() ../../gcc/cgraphunit.c:625 0x839443 analyze_functions ../../gcc/cgraphunit.c:1086 0x83a128 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2543
[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71859 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-13 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- > When using the same name for a variable and a subroutine (invalid), > experimental (--enable-checking=yes) versions 7, 6 and maybe older > ones (not tested) give an ICE. Confirmed also for 4.9 and 5.
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 Gerhard Steinmetz changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t ||-online.de --- Comment #4 from Gerhard Steinmetz --- ICE for both release and experimental : $ gfortran-6 pr70842.f90 f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241 $ gfortran-7-20160710 pr70842.f90 f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241 0x66ac54 gfc_add_component_ref(gfc_expr*, char const*) ../../gcc/fortran/class.c:241 0x66ad47 gfc_get_len_component(gfc_expr*) ../../gcc/fortran/class.c:585 0x694cb9 do_simplify ../../gcc/fortran/intrinsic.c:4150 0x69e60c gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4506 0x6e3e66 resolve_unknown_f ../../gcc/fortran/resolve.c:2718 0x6e3e66 resolve_function ../../gcc/fortran/resolve.c:3020 0x6e3e66 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6353 0x6e8a91 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10469 0x6e87eb gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:9520 0x6e8b9e gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10459 0x6eb272 resolve_codes ../../gcc/fortran/resolve.c:15667 0x6eb361 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:15701 0x6e9943 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:6236 0x6e9943 resolve_block_construct ../../gcc/fortran/resolve.c:9405 0x6e9943 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10682 0x6e87eb gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:9520 0x6f2c67 resolve_select_type ../../gcc/fortran/resolve.c:8625 0x6e9261 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10678 0x6eb272 resolve_codes ../../gcc/fortran/resolve.c:15667 0x6eb177 resolve_codes ../../gcc/fortran/resolve.c:15652
[Bug fortran/71859] ICE on same variable/subroutine name (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71859
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> When using the same name for a variable and a subroutine (invalid),
> experimental (--enable-checking=yes) versions 7, 6 and maybe older
> ones (not tested) give an ICE.
> No ICE for release versions 4.9, 5, 6, 7.
>
>
> $ cat z1.f90
> program p
>call s(1)
>x = abs(s)
> end
> subroutine s(n)
>print *, n
> end
>
Index: check.c
===
--- check.c (revision 238185)
+++ check.c (working copy)
@@ -72,6 +72,11 @@ type_check (gfc_expr *e, int n, bt type)
static bool
numeric_check (gfc_expr *e, int n)
{
+ /* Users sometime use a subroutine designator as an actual argument to
+ an intrinsic subprogram that expects an argument with a numeric type. */
+ if (e->symtree->n.sym->attr.subroutine)
+goto bandaid;
+
if (gfc_numeric_ts (&e->ts))
return true;
@@ -86,6 +91,8 @@ numeric_check (gfc_expr *e, int n)
return true;
}
+bandaid:
+
gfc_error ("%qs argument of %qs intrinsic at %L must be a numeric type",
gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
&e->where);
[Bug fortran/71861] New: ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 Bug ID: 71861 Summary: ICE in write_symbol(): bad module symbol Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- An interface with an alienated intrinsic name (or any other) : $ cat z1.f90 module m intrinsic abs abstract interface function abs(x) real :: abs, x end end interface end $ cat z2.f90 module m abstract interface function abs(x) real :: abs, x end end interface intrinsic abs end $ cat z3.f90 module m abstract interface function f(x) real :: f, x end end interface intrinsic f end $ gfortran-6 z1.f90 f951: internal compiler error: write_symbol(): bad module symbol 'x' #... $ gfortran-7-20160710 z3.f90 f951: internal compiler error: write_symbol(): bad module symbol 'x' 0x6842f1 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1312 0x6bc312 write_symbol ../../gcc/fortran/module.c:5563 0x6bc35b write_symbol1_recursion ../../gcc/fortran/module.c:5790 0x6bf185 write_symbol1 ../../gcc/fortran/module.c:5823 0x6bf185 write_module ../../gcc/fortran/module.c:5967 0x6bf185 dump_module ../../gcc/fortran/module.c:6094 0x6bf3f7 gfc_dump_module(char const*, int) ../../gcc/fortran/module.c:6137 0x6d6d06 gfc_parse_file() ../../gcc/fortran/parse.c:6068 0x718d12 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/71861] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 --- Comment #1 from Gerhard Steinmetz --- Side note : $ cat z0.f90 module m abstract interface function abs(x) real :: abs, x end end interface end $ gfortran-6 -Wall z0.f90 z0.f90:3:6: function abs(x) 1 Warning: 'abs' declared at (1) may shadow the intrinsic of the same name. In order to call the intrinsic, explicit INTRINSIC declarations may be required. [-Wintrinsic-shadow]
[Bug fortran/71862] New: ICE in gfc_add_component_ref, at fortran/class.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862 Bug ID: 71862 Summary: ICE in gfc_add_component_ref, at fortran/class.c:241 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Release versions (5, 6, 7) are bailed out, with no backtrace. Experimental versions (6, 7 tested) give a backtrace. $ cat z1.f90 program p type t integer :: n = 0 integer, pointer :: q => null() end type type(t) :: x print *, associated(x%q) x = f() print *, associated(x%q) contains function f() result (z) class(t) :: z print *, associated(z%q) end end $ gfortran-6 z1.f90 z1.f90:11:26: function f() result (z) 1 Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer (null):0: confused by earlier errors, bailing out $ gfortran-7-20160710 z1.f90 z1.f90:11:26: function f() result (z) 1 Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:241 0x66ac54 gfc_add_component_ref(gfc_expr*, char const*) ../../gcc/fortran/class.c:241 0x6ead24 resolve_ordinary_assign ../../gcc/fortran/resolve.c:9751 0x6ead24 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10570 0x6eb272 resolve_codes ../../gcc/fortran/resolve.c:15667 0x6eb361 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:15701 0x6d668a resolve_all_program_units ../../gcc/fortran/parse.c:5853 0x6d668a gfc_parse_file() ../../gcc/fortran/parse.c:6105 0x718d12 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/71862] ICE in gfc_add_component_ref, at fortran/class.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862 --- Comment #1 from Gerhard Steinmetz --- Works when "class" is changed to "type" ... $ cat z2.f90 program p type t integer :: n = 0 integer, pointer :: q => null() end type type(t) :: x print *, associated(x%q) x = f() print *, associated(x%q) contains function f() result (z) type(t) :: z print *, associated(z%q) end end $ gfortran-7-20160710 z2.f90 $ a.out F F F
[Bug c++/71863] New: wrong column location in -Wformat in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71863
Bug ID: 71863
Summary: wrong column location in -Wformat in C++
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When compiled in C mode, the following test emits warnings that point at each
of the problem directives:
$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wformat xyz.c
void f (void)
{
__builtin_printf ("%s%s", 0, 0);
}
xyz.c: In function ‘f’:
xyz.c:3:23: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘int’ [-Wformat=]
__builtin_printf ("%s%s", 0, 0);
^
xyz.c:3:25: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 3 has type ‘int’ [-Wformat=]
__builtin_printf ("%s%s", 0, 0);
^
However, when compiled in C++ mode, the column information is wrong:
$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wformat -xc++ xyz.c
void f (void)
{
__builtin_printf ("%s%s", 0, 0);
}
xyz.c: In function ‘void f()’:
xyz.c:3:33: warning: format ‘%s’ expects argument of type ‘char*’, but argument
2 has type ‘int’ [-Wformat=]
__builtin_printf ("%s%s", 0, 0);
^
xyz.c:3:33: warning: format ‘%s’ expects argument of type ‘char*’, but argument
3 has type ‘int’ [-Wformat=]
The same problem occurs with other directives. I found a long discussion of
some of the issues in bug 52952 but based on the patches referenced from there
it looks like they have been resolved (as least for C).
[Bug c++/71863] wrong column location in -Wformat in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71863 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- Bug 56856 already tracks this problem. *** This bug has been marked as a duplicate of bug 56856 ***
[Bug c++/56856] the location of Wformat warnings points *after* the format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- *** Bug 71863 has been marked as a duplicate of this bug. ***
[Bug c++/56856] the location of Wformat warnings points *after* the format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-13 Ever confirmed|0 |1 Known to fail||4.9.3, 5.3.0, 6.1.0, 7.0 --- Comment #4 from Martin Sebor --- Confirmed. See the duplicate bug 71863 for another test case.
[Bug fortran/71862] ICE in gfc_add_component_ref, at fortran/class.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> Release versions (5, 6, 7) are bailed out, with no backtrace.
> Experimental versions (6, 7 tested) give a backtrace.
>
>
> $ cat z1.f90
> program p
>type t
> integer :: n = 0
> integer, pointer :: q => null()
>end type
>type(t) :: x
>print *, associated(x%q)
>x = f()
>print *, associated(x%q)
> contains
>function f() result (z)
> class(t) :: z
> print *, associated(z%q)
>end
> end
>
>
>
> $ gfortran-6 z1.f90
> z1.f90:11:26:
>
> function f() result (z)
> 1
> Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer
> (null):0: confused by earlier errors, bailing out
>
>
>
> $ gfortran-7-20160710 z1.f90
> z1.f90:11:26:
>
> function f() result (z)
> 1
> Error: CLASS variable 'z' at (1) must be dummy, allocatable or pointer
Index: resolve.c
===
--- resolve.c (revision 238185)
+++ resolve.c (working copy)
@@ -11440,8 +11440,9 @@ resolve_fl_var_and_proc (gfc_symbol *sym
and excepted from the test. */
if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->assoc)
{
- gfc_error ("CLASS variable %qs at %L must be dummy, allocatable "
-"or pointer", sym->name, &sym->declared_at);
+ gfc_error ("CLASS variable %qs at %L shall be a dummy argument "
+"or have the POINTER or ALLOCATABLE attribute",
+sym->name, &sym->declared_at);
return false;
}
}
Index: class.c
===
--- class.c (revision 238185)
+++ class.c (working copy)
@@ -238,12 +238,14 @@ gfc_add_component_ref (gfc_expr *e, cons
/* Avoid losing memory. */
gfc_free_ref_list (*tail);
c = gfc_find_component (derived, name, true, true, tail);
- gcc_assert (c);
- for (ref = *tail; ref->next; ref = ref->next)
-;
- ref->next = next;
- if (!next)
-e->ts = c->ts;
+
+ if (c) {
+for (ref = *tail; ref->next; ref = ref->next)
+ ;
+ref->next = next;
+if (!next)
+ e->ts = c->ts;
+ }
}
[Bug c++/56856] the location of Wformat warnings points *after* the format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856
--- Comment #5 from Martin Sebor ---
I thought I'd look into this bug since it affects the testing of my patch for
bug 49905 and I'm finding out that it seems to be a general problem with C++
and function arguments. From what I can see, the C front end tracks the
locations of function arguments through the parser, passing them from function
to function, while the C++ front end doesn't. Sadly, it doesn't look like a
simple fix...
$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic -Wformat -xc++ xyz.c
void f (int, int, int);
void g (void)
{
f (0, "", 1);
}
xyz.c: In function ‘void g()’:
xyz.c:5:14: error: invalid conversion from ‘const char*’ to ‘int’
[-fpermissive]
f (0, "", 1);
^
xyz.c:1:6: note: initializing argument 2 of ‘void f(int, int, int)’
void f (int, int, int);
^
[Bug fortran/71862] ICE in gfc_add_component_ref, at fortran/class.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- F08:C407 An entity declared with the CLASS keyword shall be a dummy argument or have the ALLOCATABLE or POINTER attribute.
[Bug debug/71864] New: x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are used simultaneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71864
Bug ID: 71864
Summary: x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are
used simultaneously
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: i.nixman at autistici dot org
Target Milestone: ---
#include
__attribute__ ((__sysv_abi__))
int foo(__m128i a)
{
return(0);
}
This error occurs when this code compiled as C and C++.
>gcc -Og -mssse3 foo.c
> foo.c: In function 'foo':
> foo.c:8:1: internal compiler error: in ix86_compute_frame_layout, at
> config/i386/i386.c:11401
[Bug fortran/71860] [4.9/5/6/7 Regression] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-13 CC||marxin at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|ICE on pointing to |[4.9/5/6/7 Regression] ICE |null(mold), verify_gimple |on pointing to null(mold), |failed |verify_gimple failed Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with GCC 4.8.x
[Bug fortran/71861] [4.9/5/6/7 Regression] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-13 CC||marxin at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|ICE in write_symbol(): bad |[4.9/5/6/7 Regression] ICE |module symbol |in write_symbol(): bad ||module symbol Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with GCC 4.9 branch.
[Bug fortran/71862] [4.9/5/6/7 Regression] ICE in gfc_add_component_ref, at fortran/class.c:241
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71862 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-07-13 CC||marxin at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|ICE in |[4.9/5/6/7 Regression] ICE |gfc_add_component_ref, at |in gfc_add_component_ref, |fortran/class.c:241 |at fortran/class.c:241 Ever confirmed|0 |1 --- Comment #4 from Martin Liška --- The ICE started with GCC 4.7
[Bug debug/71864] x86_64-w64-mingw32, ICE when '-Og' & '-mssse3' are used simultaneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71864 --- Comment #1 from niXman --- This error does not occur if '-Og' is excluded. Also this error does not occur when '-O0' is used.
[Bug testsuite/71865] New: [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71865
Bug ID: 71865
Summary: [7 regression] test case
gcc.dg/diagnostic-token-ranges.c fails starting with
r237714
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at linux dot vnet.ibm.com
Target Milestone: ---
FAIL: gcc.dg/diagnostic-token-ranges.c (test for excess errors)
Excess errors:
bool
The text of some of the diagnostic messages changed and this test case needs to
be updated to better match.
One example (there are a couple) with r237713 a message was
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c:20:3:
error: unknown type name 'foo'
foo bar; /* { dg-error "unknown type name 'foo'" } */
^~~
And then after r237714
home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/diagnostic-token-ranges.c:21:3:
error: unknown type name 'foo'; did you mean 'bool'?
foo bar; /* { dg-error "unknown type name 'foo'" } */
^~~
bool
The "bool" on the last line seems to be causing the problem.
[Bug middle-end/70159] missed CSE optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159 Anton Blanchard changed: What|Removed |Added CC||anton at samba dot org --- Comment #15 from Anton Blanchard --- Created attachment 38890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38890&action=edit test case
[Bug middle-end/70159] missed CSE optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
--- Comment #16 from Anton Blanchard ---
I'm seeing a lockup in gcc with this patch on ppc64le. Run as:
gcc -O2 -c testcase.i
It gets stuck in:
#0 0x3fffb7e5e3e8 in __waitpid_nocancel ()
at ../sysdeps/unix/syscall-template.S:84
#1 0x10088c58 in pex_wait (obj=, time=0x0,
status=0x1015f080, pid=)
at ../../gcc/libiberty/pex-unix.c:134
#2 pex_unix_wait (obj=, pid=,
status=0x1015f080, time=0x0, done=, errmsg=0x3fffd750,
err=0x3fffd74c) at ../../gcc/libiberty/pex-unix.c:738
#3 0x1008762c in pex_get_status_and_time (obj=,
done=, errmsg=, err=)
at ../../gcc/libiberty/pex-common.c:534
#4 0x10088630 in pex_get_status (obj=0x1015efc0,
count=, vector=0x3fffd7e0)
at ../../gcc/libiberty/pex-common.c:554
#5 0x100101dc in execute () at ../../gcc/gcc/gcc.c:3107
#6 0x10010f04 in do_spec_1 (
spec=0x1015ec20 "-o %|.s |\n as %(asm_options) %m.s %A", inswitch=0,
soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5145
#7 0x100139e4 in process_brace_body (matched=,
starred=0, end_atom=0x1015ed3c ":-o %|.s |\n as %(asm_options) %m.s %A }",
atom=0x1015ed3b "S:-o %|.s |\n as %(asm_options) %m.s %A }",
p=0x1015ed62 "}") at ../../gcc/gcc/gcc.c:6431
#8 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#9 0x10011604 in do_spec_1 (
spec=0x1015ecf0 "
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()} %{!S:-o
%|.s |\n as %(asm_options) %m.s %A }", inswitch=0,
soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5802
#10 0x100139e4 in process_brace_body (matched=,
starred=1,
end_atom=0x100a877f "*:
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()} %{!S:-o
%|.s |\n as %(asm_options) %m.s %A } }",
atom=0x100a877b "fwpa*:
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()} %{!S:-o
%|.s |\n as %(asm_options) %m.s %A } }",
p=0x100a87f6 "}") at ../../gcc/gcc/gcc.c:6431
#11 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#12 0x10011604 in do_spec_1 (
spec=0x100a8778 "%{!fwpa*:
%{fcompare-debug=*|fdump-final-insns=*:%:compare-debug-dump-opt()} %{!S:-o
%|.s |\n as %(asm_options) %m.s %A } }",
inswitch=0, soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5802
#13 0x10011228 in do_spec_1 (spec=0x1015ec90 "%(invoke_as)",
inswitch=0, soft_matched_part=0x0) at ../../gcc/gcc/gcc.c:5917
#14 0x100139e4 in process_brace_body (matched=,
starred=0, end_atom=0x1015ec04 ":%(invoke_as)}",
atom=0x1015ebf8 "fsyntax-only:%(invoke_as)}", p=0x1015ec11 "}")
at ../../gcc/gcc/gcc.c:6431
#15 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#16 0x10011604 in do_spec_1 (
spec=0x1015ebd0 "cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}", inswitch=0, soft_matched_part=0x0) at
../../gcc/gcc/gcc.c:5802
#17 0x100139e4 in process_brace_body (matched=,
starred=0,
end_atom=0x1015eb74 ":cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}",
atom=0x1015eb73 "E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}", p=0x1015ebb7 "}") at ../../gcc/gcc/gcc.c:6431
#18 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#19 0x10011604 in do_spec_1 (
spec=0x1015eb70 "%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}", inswitch=0, soft_matched_part=0x0) at
../../gcc/gcc/gcc.c:5802
#20 0x100139e4 in process_brace_body (matched=,
starred=0,
end_atom=0x1015eb15 ":%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}",
atom=0x1015eb13 "MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}", p=0x1015eb5e "}") at ../../gcc/gcc/gcc.c:6431
#21 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#22 0x10011604 in do_spec_1 (
spec=0x1015eb10 "%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)}}}", inswitch=0, soft_matched_part=0x0)
at ../../gcc/gcc/gcc.c:5802
#23 0x100139e4 in process_brace_body (matched=,
starred=0,
end_atom=0x100a789c ":%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)",
atom=0x100a789b "M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)", p=0x100a78ec "}") at
../../gcc/gcc/gcc.c:6431
#24 handle_braces (p=) at ../../gcc/gcc/gcc.c:6345
#25 0x10011604 in do_spec_1 (
spec=0x100a7898 "%{!M:%{!MM:%{!E:cc1 -fpreprocessed %i %(cc1_options)
%{!fsyntax-only:%(invoke_as)", inswitch=0, soft_matched_part=0x0)
at ../../gcc/gcc/gcc.c:5802
#26 0x10012878 in do_spec_2 (spec=)
at ../../gcc/gcc/gcc.c:4841
#27 0x10014514 in do_spec (spec=)
at ../../gcc/gcc/gcc.c:4808
#28 0x1001479c in driver::do_spec_on_infiles (this=0x3108)
at ../../gcc/gcc/gcc.c:8076
#29 0x10003138 in driver::main (this=0x3108
[Bug middle-end/70159] missed CSE optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159 --- Comment #17 from Andrew Pinski --- (In reply to Anton Blanchard from comment #16) > I'm seeing a lockup in gcc with this patch on ppc64le. Run as: > > gcc -O2 -c testcase.i Can you file a new bug for this? Also your backtrace is just for the driver.
[Bug c/71858] Surprising suggestions for misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71858 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Indeed, DECL_ANTICIPATED (for C++) decls and for C b->invisible bindings should not be considered.
[Bug tree-optimization/71866] New: gcc locks up after fix for PR70159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71866 Bug ID: 71866 Summary: gcc locks up after fix for PR70159 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org Target Milestone: --- Created attachment 38891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38891&action=edit Test case The attached testcase is locking up on ppc64le when run with -O2. #0 0x10733df8 in iterative_hash_hashval_t (val=2902752560, val2=2655680748) at ../../gcc/gcc/inchash.h:156 #1 0x10ac2004 in phi_trans_add (pred=0x3fffb57d8818, e=0x11b553c0, entry=0x3fffe3f8) at ../../gcc/gcc/tree-ssa-pre.c:620 #2 phi_translate (expr=0x11b553c0, set1=0x11b369a8, set2=0x0, pred=0x3fffb57d8818, phiblock=0x3fffb57d6f50) at ../../gcc/gcc/tree-ssa-pre.c:1815 #3 0x10ac4744 in do_pre_regular_insertion (dom=0x3fffb57d6e80, block=0x3fffb57d6f50) at ../../gcc/gcc/tree-ssa-pre.c:3266 #4 insert_aux (block=0x3fffb57d6f50, do_pre=true, do_hoist=true) at ../../gcc/gcc/tree-ssa-pre.c:3679 #5 0x10ac43e0 in insert_aux (block=0x3fffb57d6e80, do_pre=true, do_hoist=true) at ../../gcc/gcc/tree-ssa-pre.c:3693 #6 0x10ac43e0 in insert_aux (block=0x3fffb57d6db0, do_pre=, do_hoist=) at ../../gcc/gcc/tree-ssa-pre.c:3693 #7 0x10ac74b4 in insert () at ../../gcc/gcc/tree-ssa-pre.c:3717 #8 (anonymous namespace)::pass_pre::execute (this=, fun=0x3fffb5848b20) at ../../gcc/gcc/tree-ssa-pre.c:5082 #9 0x107b9fe4 in execute_one_pass (pass=0x11950c30) at ../../gcc/gcc/passes.c:2344 #10 0x107ba6d8 in execute_pass_list_1 (pass=0x11950c30) at ../../gcc/gcc/passes.c:2428 #11 0x107ba6f0 in execute_pass_list_1 (pass=0x1194fbb0) at ../../gcc/gcc/passes.c:2429 #12 0x107ba798 in execute_pass_list (fn=, pass=) at ../../gcc/gcc/passes.c:2439 #13 0x103bea34 in cgraph_node::expand (this=0x3fffb5861870) at ../../gcc/gcc/cgraphunit.c:1983 #14 0x103c0b6c in expand_all_functions () at ../../gcc/gcc/cgraphunit.c:2119 #15 symbol_table::compile (this=0x3fffb563) at ../../gcc/gcc/cgraphunit.c:2475 #16 0x103c3914 in symbol_table::compile (this=0x3fffb563) at ../../gcc/gcc/cgraphunit.c:2380 #17 symbol_table::finalize_compilation_unit (this=0x3fffb563) at ../../gcc/gcc/cgraphunit.c:2565 #18 0x108c4a1c in compile_file () at ../../gcc/gcc/toplev.c:490 #19 0x101b12fc in do_compile () at ../../gcc/gcc/toplev.c:1998 #20 toplev::main (this=0x30d6, argc=3, argv=0x34f8) at ../../gcc/gcc/toplev.c:2132 #21 0x101b3344 in main (argc=, argv=0x34f8) at ../../gcc/gcc/main.c:39
[Bug c/71858] Surprising suggestions for misspellings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71858
--- Comment #2 from Jakub Jelinek ---
--- gcc/c/c-decl.c.jj 2016-06-24 12:59:22.0 +0200
+++ gcc/c/c-decl.c 2016-07-13 22:40:23.410658411 +0200
@@ -4021,7 +4021,7 @@ lookup_name_fuzzy (tree name, enum looku
for (c_scope *scope = current_scope; scope; scope = scope->outer)
for (c_binding *binding = scope->bindings; binding; binding =
binding->prev)
{
- if (!binding->id)
+ if (!binding->id || binding->invisible)
continue;
/* Don't use bindings from implicitly declared functions,
as they were likely misspellings themselves. */
indeed fixes this. Well, it suggests:
pr71858.c: In function ‘main’:
pr71858.c:4:10: warning: implicit declaration of function ‘bar’; did you mean
‘char’? [-Wimplicit-function-declaration]
return bar ();
^~~
char
instead. Which actually also isn't a very good suggestion for C (unlike C++),
it would be useful to consider only FUNCTION_DECLs in this case.
[Bug middle-end/70159] missed CSE optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159 --- Comment #18 from Anton Blanchard --- Urgh too early in the morning for me. PR71866 created, with the correct backtrace.
[Bug c++/56856] the location of Wformat warnings points *after* the format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856 --- Comment #6 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #5) > I thought I'd look into this bug since it affects the testing of my patch > for bug 49905 and I'm finding out that it seems to be a general problem with > C++ and function arguments. From what I can see, the C front end tracks the > locations of function arguments through the parser, passing them from > function to function, while the C++ front end doesn't. Sadly, it doesn't > look like a simple fix... This happens for "expressions" that don't have a location (such as constants, variable uses, etc.). I'm not even sure that passing the location is enough, since the C++ parser will do a lot of tentative parsing and, by the time you call the function, input_location is too far away and the original location of the argument is lost. You may need to store the locations together with the arguments when they are parsed and somehow keep them together throughout the C++ FE. Which is of course redundant when the expressions actually have a location. At the end, everything comes back to fixing PR43486
[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 --- Comment #11 from vsz.bugzilla at emailuser dot net --- Thank you, Nick. I'd be glad to make tests with a binary pre-built using your patches, but building binutils from source myself, appears to be a too long shot at this point. Is there someone who could help out with test binutils binaries?
[Bug target/71731] incorrect result for vectorized char rotate with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71731 --- Comment #3 from acsawdey at gcc dot gnu.org --- This appears to be fixed by the fix for PR71805.
[Bug target/71805] incorrect code for test pr45752.c with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71805 --- Comment #7 from Bill Schmidt --- *** Bug 71731 has been marked as a duplicate of this bug. ***
[Bug target/71731] incorrect result for vectorized char rotate with -mcpu=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71731 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Bill Schmidt --- Thus closing. Thanks, Aaron! *** This bug has been marked as a duplicate of bug 71805 ***
[Bug fortran/70842] [4.9/5/6/7 Regression] internal compiler error with character members within a polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70842 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to Gerhard Steinmetz from comment #4) > ICE for both release and experimental : > > > $ gfortran-6 pr70842.f90 > f951: internal compiler error: in gfc_add_component_ref, at > fortran/class.c:241 > With the patch I posted earlier today and code in comment #1, I see gfc7 -c a.f90 a.f90:14:30: print*, len(me%string) 1 Error: Data transfer element at (1) cannot be polymorphic unless it is processed by a defined input/output procedure I don't use CLASS and know little about its expected behavior. Is the above even remotely right?
[Bug c++/71867] New: Optimizer generates code dereferencing a null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71867
Bug ID: 71867
Summary: Optimizer generates code dereferencing a null pointer
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vz-gcc at zeitlins dot org
Target Milestone: ---
First of all, I'd like to say that I'm reporting this bug because it looks like
a rather bad problem in gcc to me, but I don't have any simple example
reproducing it because I couldn't produce one even in spite of spending some
time on this, so please feel free to close if you're not interested in
debugging this.
The problem in question is that, according to the original bug report (see
http://trac.wxwidgets.org/ticket/17483), code generated by gcc -O2 for this
method (omitting parts of the class, you can see the full version at
https://github.com/wxWidgets/wxWidgets/blob/v3.1.0/include/wx/rtti.h#L86):
class wxClassInfo {
public:
...
bool IsKindOf(const wxClassInfo *info) const
{
return info != 0 &&
( info == this ||
( m_baseInfo1 && m_baseInfo1->IsKindOf(info) ) ||
( m_baseInfo2 && m_baseInfo2->IsKindOf(info) ) );
}
private:
const wxClassInfo *m_baseInfo1;
const wxClassInfo *m_baseInfo2;
};
generates the code which crashes during run-time because
m_baseInfo1->IsKindOf() call is done even when m_baseInfo1 is null. The crash
doesn't happen with -O0 or even with an attribute optimize("O0") applied to
just this function.
Unfortunately, extracting this class and compiling just it with -O2 doesn't
show the problem, there must be something else triggering it and making the
optimizer assume that the pointers can never be null (which is true for almost
all classes, but not for the root class of the hierarchy, which is constructed
with null base class info pointer). And, again, I tried, but I couldn't find
what it was.
Rewriting the expression as a sequence of statements, as done in
https://github.com/wxWidgets/wxWidgets/commit/aa3acfdd15eff1519a41b48a2babe4cba75660f9,
fixes the bug, so from my point of view this particular problem is solved, but,
again, I find it rather worrying if the optimizer can miscompile quite
straightforward code like above, so I still wanted to report it. If you'd like
to look at it, please get any version of wxWidgets prior to the commit above
(e.g. 3.1.0 release) and build it under Windows. Of course, please let me know
if you need any more information -- other than a simple reproducible test case
which I, unfortunately, just can't make.
Thanks in advance!
[Bug c++/71711] [6/7 Regression] ICE on valid C++1z code with fold expression: tree check: expected tree_vec, have expr_pack_expansion in tsubst_unary_left_fold, at cp/pt.c:10792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71711 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/70926] Libiberty Demangler segfaults (5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70926 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #1 from Jeffrey A. Law --- Fixed by commit on trunk --- Comment #2 from Jeffrey A. Law --- Author: law Date: Wed Jul 13 22:06:09 2016 New Revision: 238313 URL: https://gcc.gnu.org/viewcvs?rev=238313&root=gcc&view=rev Log: PR c++/70926 * cplus-dem.c: Handle large values and overflow when demangling length variables. (demangle_template_value_parm): Read only until end of mangled string. (do_hpacc_template_literal): Likewise. (do_type): Handle overflow when demangling array indices. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cplus-dem.c trunk/libiberty/testsuite/demangle-expected
[Bug c++/70926] Libiberty Demangler segfaults (5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70926 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #1 from Jeffrey A. Law --- Fixed by commit on trunk
[Bug c/71868] New: internal compiler error: in compute_working_sets, at gcov-io.c:1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71868 Bug ID: 71868 Summary: internal compiler error: in compute_working_sets, at gcov-io.c:1006 Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nghia.huynh at nxp dot com Target Milestone: --- Got the following error while building nginx 1.8.1 with -lgcov internal compiler error: in compute_working_sets, at gcov-io.c:1006
[Bug c/71868] internal compiler error: in compute_working_sets, at gcov-io.c:1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71868 --- Comment #1 from nghia.huynh at nxp dot com --- Created attachment 38892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38892&action=edit gcc info and log preprocessed files size exceed 1kb size limit
[Bug c/71869] New: __builtin_isgreater raises an invalid exception on PPC64 using __float128 inputs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869
Bug ID: 71869
Summary: __builtin_isgreater raises an invalid exception on
PPC64 using __float128 inputs.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: murphyp at linux dot vnet.ibm.com
Target Milestone: ---
#include
volatile __float128 qnan = __builtin_nanq("");
int main()
{
feclearexcept(FE_INVALID);
if (__builtin_isgreater(1.0Q, qnan)) puts("isgreater is broken");
if (fetestexcept(FE_INVALID)) puts("invalid wrongly set for quiet
comparison");
return 0;
}
Using a recent gcc-6-branch checkout:
gcc -mfloat128 -mcpu=power8
I assume this also the case for the other __builtin_is{ordering} functions too.
This causes a substantial number of test failures for float128 when shoehorned
into the glibc libm test suite. (Note, this is much hacked up local copy of
glibc to verify the compiler support for float128 is sufficient for glibc).
x86 appears to stick a call to __unordtf2 before attempting to call the
comparison function. I assume PPC64 should be doing a similar for KFmode.
[Bug c++/56856] the location of Wformat warnings points *after* the format string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856 --- Comment #7 from Martin Sebor --- Thanks for the background and the pointer. Is this report then a duplicate of bug 43486?
[Bug c/71870] New: wrong location of "%n$" directive in -Wformat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71870
Bug ID: 71870
Summary: wrong location of "%n$" directive in -Wformat
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When encountering an invalid format specifier, the GCC -Wformat checker issues
a warning pointing to the specifier in the format string. However, when it
encounters the dollar sign in an otherwise valid POSIX format directive, GCC
issues a warning that doesn't point to the directive. Modulo the difficulties
discussed in bug 52952 and related there should be no problem pointing to the
'$' in the basic cases similarly to what's done for the 'r' in the test case
below.
$ cat xyz.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wall -Wextra -Wpedantic xyz.c
char d [4];
void f (void)
{
__builtin_sprintf (d, "%r");
__builtin_sprintf (d, "%2$i%1$i", 1, 234);
}
xyz.c: In function ‘f’:
xyz.c:5:27: warning: unknown conversion type character ‘r’ in format
[-Wformat=]
__builtin_sprintf (d, "%r");
^
xyz.c:7:3: warning: ISO C does not support %n$ operand number formats
[-Wformat]
__builtin_sprintf (d, "%2$i%1$i", 1, 234);
^
[Bug bootstrap/66319] [6 Regression] gcov-tool.c:84:65: error: invalid conversion from 'int (*)(const c har*, const stat*, int, FTW*)' to 'int (*)(const char*, const stat*, int, FTW)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 --- Comment #18 from jim.wilson at linaro dot org --- On 07/12/2016 09:36 AM, bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66319 > > --- Comment #16 from The Written Word com> --- > (In reply to John David Anglin from comment #15) >> Steve Ellcey used to support HP-UX/IA64 but he moved on to MIPS. Don't >> know Jim Wilson's status. I've never had access to HP-UX/IA64. I've only used ia64-linux. I no longer have an IA-64 machine at home. I don't have access to IA-64 at work, and there is no IA-64 hardware in the gcc compile farm. I retain a lot of knowledge about how IA-64 works, but with no hardware access, and no HP-UX access, there isn't much I can do to help. Jim
[Bug c/71870] wrong location of "%n$" directive in -Wformat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71870
--- Comment #1 from Martin Sebor ---
The following output with my WIP patch for bug 49905 shows that at least in C
the correct location information is available (the second warning):
$ cat xyz.c && /build/gcc-49905/gcc/xgcc -B /build/gcc-49905/gcc -O2 -S -Wall
-Wextra -Wpedantic xyz.c
char d [4];
void f (void)
{
__builtin_sprintf (d, "%3$i%1$i", 1, 234);
}
xyz.c: In function ‘f’:
xyz.c:5:3: warning: ISO C does not support %n$ operand number formats
[-Wformat]
__builtin_sprintf (d, "%3$i%1$i", 1, 234);
^
xyz.c:5:3: warning: operand number out of range in format [-Wformat=]
xyz.c:5:27: warning: numbered argument value ‘3’ exceeds the number of provided
arguments ‘2’ [-Wformat-length=]
__builtin_sprintf (d, "%3$i%1$i", 1, 234);
^
[Bug c++/71871] New: ICE on mixing templates and vector extensions ternary operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71871 Bug ID: 71871 Summary: ICE on mixing templates and vector extensions ternary operator Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mirq-gccboogs at rere dot qmqm.pl Target Milestone: --- Created attachment 38893 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38893&action=edit test case Attached causes an ICE. $ g++ -c a.cc a.cc: In function ‘void foo() [with unsigned int N = 0u]’: a.cc:7:2: internal compiler error: in gimplify_expr, at gimplify.c:8858 x = x ? x : -1; ^ 0x74c6d9 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../src/gcc/gimplify.c:8858 0xefc41c internal_get_tmp_var ../../src/gcc/gimplify.c:555 0x12b62d1 get_initialized_tmp_var(tree_node*, gimple_statement_base**, gimple_statement_base**) ../../src/gcc/gimplify.c:598 0x12b62d1 gimplify_save_expr ../../src/gcc/gimplify.c:4887 0xef8d54 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../src/gcc/gimplify.c:8412 0xef80cf gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../src/gcc/gimplify.c:8228 0x7516c5 gimplify_init_constructor ../../src/gcc/gimplify.c:4103 0xefbeb0 gimplify_modify_expr_rhs ../../src/gcc/gimplify.c:4274 0xefb4a9 gimplify_modify_expr ../../src/gcc/gimplify.c:4603 0xef778f gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../src/gcc/gimplify.c:8126 0xefc82b gimplify_stmt(tree_node**, gimple_statement_base**) ../../src/gcc/gimplify.c:5545 0xefc82b gimplify_and_add(tree_node*, gimple_statement_base**) ../../src/gcc/gimplify.c:423 0xefc82b internal_get_tmp_var ../../src/gcc/gimplify.c:568 0xef7c8c get_formal_tmp_var(tree_node*, gimple_statement_base**) ../../src/gcc/gimplify.c:589 0xef7c8c gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../src/gcc/gimplify.c:9050 0x74b6d6 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../src/gcc/gimplify.c:8844 0xefb54b gimplify_modify_expr ../../src/gcc/gimplify.c:4644 0xef778f gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) ../../src/gcc/gimplify.c:8126 0xef716e gimplify_stmt(tree_node**, gimple_statement_base**) ../../src/gcc/gimplify.c:5545 0xef8570 gimplify_cleanup_point_expr ../../src/gcc/gimplify.c:5321 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.0-6' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,jau Thread model: posix gcc version 5.4.0 20160609 (Debian 5.4.0-6) also fails on: $ g++ -v Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.9.real COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10)
