[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71578 Markus Trippelsdorf changed: What|Removed |Added Keywords||wrong-code CC||marxin at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #2 from Markus Trippelsdorf --- Started with r237556: commit 1176073cc1a63f14198c3ba0a02c8f5a52442c2f Author: marxin Date: Fri Jun 17 14:28:57 2016 + Change PRED_LOOP_EXIT from 92 to 85.
[Bug target/71318] Can't disable ISAs via function attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71318 Andrew Pinski changed: What|Removed |Added Component|middle-end |target --- Comment #3 from Andrew Pinski --- Look at the function init_optabs, it calls init_all_optabs. init_tree_optimization_optabs will also call init_all_optabs too. Maybe the problem is init_tree_optimization_optabs is called before ix86_option_override_internal .
[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71578 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- (In reply to Markus Trippelsdorf from comment #2) > Started with r237556: > > commit 1176073cc1a63f14198c3ba0a02c8f5a52442c2f > Author: marxin > Date: Fri Jun 17 14:28:57 2016 + > > Change PRED_LOOP_EXIT from 92 to 85. This definitely exposed a latent bug somewhere.
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 --- Comment #14 from Jakub Jelinek --- (In reply to Uroš Bizjak from comment #12) > The "Once gcc is able ..." part in the comment implies that simply returning > different mode based on the incoming rtx code argument won't work. OTOH, > this is ancient comment, so things *could* work now. E.g. fold-const.c (invert_tree_comparison) now has: if (honor_nans && flag_trapping_math && code != EQ_EXPR && code != NE_EXPR && code != ORDERED_EXPR && code != UNORDERED_EXPR) return ERROR_MARK; so at least for -ftrapping-math and no -ffast-math suboptions it should do the right thing, but we had this for years (e.g. 4.4 gave up always, instead of properly being able to invert EQ/NE/ORDERED/UNORDERED. So, shall the backend emit different code for -ftrapping-math vs. -fno-trapping-math, perhaps by using the non-trapping insns for the latter for all comparisons (both scalar and vector)?
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 --- Comment #15 from Jakub Jelinek --- Anyway, to make progress for KNL, would you be ok with a patch containing just the ix86_fp_cmp_code_to_pcmp_immediate hunk tweaked so that it emits the same thing as %D, and as a follow-up we can try to handle -ftrapping-math and all that stuff in all places. Ok?
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 Uroš Bizjak changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #16 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #14) > So, shall the backend emit different code for -ftrapping-math vs. > -fno-trapping-math, perhaps by using the non-trapping insns for the latter > for all comparisons (both scalar and vector)? Maybe Honza (CC'd) has some ideas.
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 --- Comment #17 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #15) > Anyway, to make progress for KNL, would you be ok with a patch containing > just the ix86_fp_cmp_code_to_pcmp_immediate hunk tweaked so that it emits > the same thing as %D, and as a follow-up we can try to handle > -ftrapping-math and all that stuff in all places. Ok? Yes, let's consider this PR to fix the ICE, and handle -ftrapping-math issue in other mentioned PRs in a separate way.
[Bug c/71574] ICE on code with alloc_align attribute on x86_64-linux-gnu: in default_conversion, at c/c-typeck.c:2126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71574 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-06-20 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/71583] ICE on invalid code on x86_64-linux-gnu (in c_parser_postfix_expression_after_paren_type, at c/c-parser.c:8192)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71583 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c/71573] ICE on invalid C code on x86_64-linux-gnu (tree check: expected function_decl, have var_decl in implicitly_declare)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71573 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-06-20 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/71589] New: Atomic operation on a non-atomic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71589
Bug ID: 71589
Summary: Atomic operation on a non-atomic variable
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wolfgang.roe...@gi-de.com
Target Milestone: ---
Hi,
I would like to post a bug report for the GNU C/C++ compiler 6.1.1.
We use the compiler to generate code for a PowerPC processor.
Invokation line for the GNU C compiler:
ccppc -c -x c -std=gnu11 -Wall -Werror -g -mcpu=e6500 -m32
-maltivec -mvrsave -ftls-model=local-exec -msdata=sysv
-fno-common -fno-openmp -mbig -mmultiple -mno-string -misel
-mstrict-align -fverbose-asm -G 8 -O3
-I
-D
X.C -oX.O
// file X.C
#include "stdatomic.h"
int* p0;
void bug (void)
{
atomic_fetch_add_explicit (&p0, 1, memory_order_relaxed);
}
The compiler accepts this programm even though p0 is a non-atomic pointer.
I think this is not standard conforming. The C11 standard decribes the
atomic_fetch functions as expecting a pointer to an atomic type (see
7.17.1/5 and 7.17.7.5/1).
With kind regards
W. Roehrl
[Bug fortran/71194] ICE on compilation with fcheck=all ; -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71194 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-20 CC||burnus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Tobias Burnus --- The problem on GCC source level is in gfc_trans_pointer_assignment (trans-expr.c): 7936tmp = gfc_create_var (tmp, "ptrtemp"); 7937lse.descriptor_only = 0; 7938lse.expr = tmp; 7939lse.direct_byref = 1; 7940gfc_conv_expr_descriptor (&lse, expr2); where lse.expr == NULL_TREE after that call. Looking at the dump (and the source below), w/o bound checking, a "ptrtemp" is generated and passed to the function: conv2real (&ptrtemp.12, D.3483); If one traces the -fcheck=bound case, the gfc_conv_expr_descriptor call leads to a call to gfc_conv_procedure_call, which does: if (byref) ... /* Add the function call to the pre chain. There is no expression. */ gfc_add_expr_to_block (&se->pre, se->expr); se->expr = NULL_TREE; Hence, lse.expr == NULL_TREE, which fails later on. [Side note: If one sets lse.direct_byref to 0, it compiles as code following immediately after the NULL_TREE sets se->expr and, hence, lse.expr again, but as "conv2real" is called with "atmp", looking at "ptrtemp" will lead to randomly wrong results.]
[Bug c++/71590] New: G++ template function initialize with wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71590
Bug ID: 71590
Summary: G++ template function initialize with wrong type
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markowitz73 at gmail dot com
Target Milestone: ---
The source code is as below:
//source start
#include
template
std::string func(T a, int b) {
std::string x;
int y;
if (b == 1) {
x = a;
} else if (b == 2) {
y = a;
}
return x;
}
int main() {
std::string c = func(1, 1);
return 0;
}
//source ends
this file got compiled successfully. Since there is no overload operator=(int)
version for std::string, so I think that I may came across with a bug.
Anything maybe useful:
I tried to output the std::string object which was assigned by an integer, it
shows
that the string was initialized by a char(the first argument 1 was treated as a
char), and the output is ASCII represented by that integer.
Compile Option:
g++ -o source.cpp main
Compiler Info:
g++ -v shows:Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-17) (GCC)
[Bug sanitizer/67865] ASAN crashes on thread creation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67865 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from dominik.stras...@onespin-solutions.com --- Works fine with GCC 6.1, let's forget about this issue.
[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-06-20 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Please attache a preprocessed file that causes the crash (that's the .i or .ii file that you can get by adding --save-temps to the compiler invocation)
[Bug libstdc++/71579] type_traits miss checks for type completeness in some traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579 --- Comment #1 from Jonathan Wakely --- Your example has undefined behaviour, the requirements in the standard are requirements on your use of the trait. If you use it wrong it doesn't work.
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #18 from Jakub Jelinek --- Created attachment 38729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38729&action=edit gcc7-pr71559.patch Untested patch I'm going to bootstrap/regtest then. The test coverage should cover all the comparisons except of LTGT, and test there everything but FE_INEXACT, for SSE2, AVX and AVX512F.
[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584 --- Comment #2 from Jeff Bai --- Here you go.
[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584 --- Comment #3 from Jeff Bai --- Created attachment 38730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38730&action=edit Temporary .ii file for MixerWorkerThread.cpp (the invoking file)
[Bug c++/71584] Internal Error compiling LMMS on ARM (Endian Little)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584 --- Comment #4 from Jeff Bai --- I compressed the .ii file with tar.xz as the original file is larger than 1000KB.
[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71578 --- Comment #4 from Markus Trippelsdorf --- (In reply to Andrew Pinski from comment #3) > (In reply to Markus Trippelsdorf from comment #2) > > Started with r237556: > > > > commit 1176073cc1a63f14198c3ba0a02c8f5a52442c2f > > Author: marxin > > Date: Fri Jun 17 14:28:57 2016 + > > > > Change PRED_LOOP_EXIT from 92 to 85. > > This definitely exposed a latent bug somewhere. Yeah. I will try to bisect with PRED_LOOP_EXIT set to 85...
[Bug rtl-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71588 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-06-20 CC||jakub at gcc dot gnu.org Summary|ICE on valid code at -O2|[4.9/5/6/7 Regression] ICE |and -O3 on |on valid code at -O2 and |x86_64-linux-gnu: in|-O3 on x86_64-linux-gnu: in |execute_todo, at|execute_todo, at |passes.c:2009 |passes.c:2009 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Most likely started with my r179279. Guess easiest would be for builtins that aren't meant to be const or pure give up on all tree-ssa-strlen.c optimizations if somebody misattributes them.
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #5 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 11:01:13 2016 New Revision: 237589 URL: https://gcc.gnu.org/viewcvs?rev=237589&root=gcc&view=rev Log: gcc/ PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const). gcc/testsuite/ PR target/71103 * gcc.target/avr/torture/pr71103-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #6 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 11:20:27 2016 New Revision: 237591 URL: https://gcc.gnu.org/viewcvs?rev=237591&root=gcc&view=rev Log: gcc/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const, symbol_ref,label_ref). gcc/testsuite/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * gcc.target/avr/pr71103.c: New test. * gcc.target/avr/torture/pr71103-2.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/pr71103.c branches/gcc-6-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/avr/avr.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/71578] [7 Regression] segfault during LTO/PGO bootstrap on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71578 --- Comment #5 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #4) > (In reply to Andrew Pinski from comment #3) > > (In reply to Markus Trippelsdorf from comment #2) > > > Started with r237556: > > > > > > commit 1176073cc1a63f14198c3ba0a02c8f5a52442c2f > > > Author: marxin > > > Date: Fri Jun 17 14:28:57 2016 + > > > > > > Change PRED_LOOP_EXIT from 92 to 85. > > > > This definitely exposed a latent bug somewhere. > > Yeah. I will try to bisect with PRED_LOOP_EXIT set to 85... Bisection is impossible because of: /home/trippels/bin/ld: error: /home/trippels/gcc_build_dir_/./prev-gcc/libgcov.a(_gcov.o): multiple definition of '__gcov_error_file' (I ran "git bisect skip" three times, but I still hit this issue.) r236761 LTO/PGO bootstrapped fine with PRED_LOOP_EXIT set to 85.
[Bug c++/71584] [6/7 Regression] internal compiler error: in cxx_eval_call_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|WAITING |NEW
Target Milestone|--- |6.2
Summary|Internal Error compiling|[6/7 Regression] internal
|LMMS on ARM (Endian Little) |compiler error: in
||cxx_eval_call_expression
Known to fail||6.1.0, 7.0
--- Comment #5 from ktkachov at gcc dot gnu.org ---
Thanks, I've confirmed it on arm, aarch64 and x86_64. It looks like a C++
frontend issue. A reduced testcase is:
class QBasicAtomicPointer {
public:
typedef int *Type;
constexpr QBasicAtomicPointer(Type);
};
template class QAtomicPointer : QBasicAtomicPointer {
public:
constexpr QAtomicPointer(T *value = 0) : QBasicAtomicPointer(value) {}
};
class JobQueue {
void m_fn1();
QAtomicPointer m_items[4];
} MixerWorkerThreadglobalJobQueue;
void JobQueue::m_fn1() {
int *_job;
m_items[1] = _job;
}
ICEs with just -fdeclone-ctor-dtor and doesn't ICE without.
The backtrace (on GCC 6) is:
MixerWorkerThread.ii:11:7: internal compiler error: in
cxx_eval_call_expression, at cp/constexpr.c:1455
class JobQueue {
^~~~
0x7f2526 cxx_eval_call_expression
$SRC/gcc/cp/constexpr.c:1455
0x7f31a8 cxx_eval_constant_expression
$SRC/gcc/cp/constexpr.c:3563
0x7ee4d4 cxx_eval_outermost_constant_expr
$SRC/gcc/cp/constexpr.c:4128
0x7fa511 maybe_constant_init(tree_node*, tree_node*)
$SRC/gcc/cp/constexpr.c:4445
0x7388ab build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
$SRC/gcc/cp/init.c:4177
0x7d2540 cp_gimplify_expr(tree_node**, gimple**, gimple**)
$SRC/gcc/cp/cp-gimplify.c:594
0xa8064d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10201
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa81e20 gimplify_cleanup_point_expr
$SRC/gcc/gimplify.c:5464
0xa81e20 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10657
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa8691f gimplify_bind_expr
$SRC/gcc/gimplify.c:1142
0xa81ff0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10491
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa81093 gimplify_statement_list
$SRC/gcc/gimplify.c:1537
0xa81093 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
$SRC/gcc/gimplify.c:10709
0xa858e6 gimplify_stmt(tree_node**, gimple**)
$SRC/gcc/gimplify.c:5688
0xa87723 gimplify_body(tree_node*, bool)
$SRC/gcc/gimplify.c:11438
0xa87e56 gimplify_function_tree(tree_node*)
$SRC/gcc/gimplify.c:11594
0x904a87 cgraph_node::analyze()
$SRC/gcc/cgraphunit.c:625
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c++/71584] [6/7 Regression] internal compiler error: in cxx_eval_call_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71584 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from ktkachov at gcc dot gnu.org --- Having done that, it looks like it's a duplicate... *** This bug has been marked as a duplicate of bug 71092 ***
[Bug c++/71092] [6/7 Regression] ICE: in cxx_eval_call_expression, at cp/constexpr.c:1449; only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71092 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||jeffbai at aosc dot xyz --- Comment #8 from ktkachov at gcc dot gnu.org --- *** Bug 71584 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/71591] New: SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71591 Bug ID: 71591 Summary: SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Compiler output: $ echo '' | x86_64-pc-linux-gnu-gcc -E -fself-test -xc - # 1 "" # 1 "" # 1 "" # 31 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "" 2 # 1 "" cc1: internal compiler error: Segmentation fault 0xbc434f crash_signal /repo/gcc-trunk/gcc/toplev.c:335 0x1576a3d test_uncond_jump /repo/gcc-trunk/gcc/rtl-tests.c:90 0x1576fd4 selftest::rtl_tests_c_tests() /repo/gcc-trunk/gcc/rtl-tests.c:109 0x1536d94 selftest::run_tests() /repo/gcc-trunk/gcc/selftest-run-tests.c:57 0xbc5979 toplev::run_self_tests() /repo/gcc-trunk/gcc/toplev.c:2057 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-237587-checking-yes-rtl-df-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-237587-checking-yes-rtl-df-nographite-amd64 Thread model: posix gcc version 7.0.0 20160620 (experimental) (GCC)
[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71529 --- Comment #3 from Ilya Enkovich --- Author: ienkovich Date: Mon Jun 20 11:35:02 2016 New Revision: 237592 URL: https://gcc.gnu.org/viewcvs?rev=237592&root=gcc&view=rev Log: gcc/ Backport from mainline r237484. 2016-06-15 Ilya Enkovich PR middle-end/71529 * ipa-chkp.c (chkp_build_instrumented_fndecl): Fix DECL_CONTEXT for copied arguments. gcc/testsuite/ Backport from mainline r237484. 2016-06-15 Ilya Enkovich PR middle-end/71529 * gcc.target/i386/pr71529.C: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/i386/pr71529.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/ipa-chkp.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71588 Jakub Jelinek changed: What|Removed |Added Component|rtl-optimization|tree-optimization Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |4.9.4
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #7 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 11:55:11 2016 New Revision: 237593 URL: https://gcc.gnu.org/viewcvs?rev=237593&root=gcc&view=rev Log: gcc/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const, symbol_ref,label_ref). gcc/testsuite/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * gcc.target/avr/pr71103.c: New test. * gcc.target/avr/torture/pr71103-2.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/pr71103.c branches/gcc-5-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/avr.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/71549] ICE on valid code at -O2 and -O3 with -g enabled in 64-bit mode on x86_64-linux-gnu: in simplify_subreg, at simplify-rtx.c:5952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71549 H.J. Lu changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #6 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01398.html
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 --- Comment #8 from Georg-Johann Lay --- Author: gjl Date: Mon Jun 20 12:02:36 2016 New Revision: 237594 URL: https://gcc.gnu.org/viewcvs?rev=237594&root=gcc&view=rev Log: gcc/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * config/avr/avr.md (movqi): Handle loading subreg:qi (const, symbol_ref,label_ref). gcc/testsuite/ Backport from 2016-06-20 trunk r237589, r236558. PR target/71103 * gcc.target/avr/pr71103.c: New test. * gcc.target/avr/torture/pr71103-2.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/pr71103.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/torture/pr71103-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/avr.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/71588] [4.9/5/6/7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in execute_todo, at passes.c:2009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71588 --- Comment #3 from Jakub Jelinek --- Created attachment 38731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38731&action=edit gcc7-pr71588.patch Untested fix.
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #13 from Marc Glisse --- (In reply to Jonathan Wakely from comment #6) > Which are the relevant classes? It seems to me that we want to tag almost > everything except a few RAII types such as std::lock_guard and > std::unique_lock, which would be quite tedious. It's certainly applicable > on all containers, and most streams except fstreams (which have constructors > with side-effects.) __attribute__((unused)) on types seems to exist precisely for the reverse situation where gcc would warn by default, and we would mark the odd class that is meant to be used this way: "When attached to a type (including a union or a struct), this attribute means that variables of that type are meant to appear possibly unused. GCC does not produce a warning for any variables of that type, even if the variable appears to do nothing. This is often the case with lock or thread classes, which are usually defined and then not referenced, but contain constructors and destructors that have nontrivial bookkeeping functions." I would be in favor of: - mark the few relevant types in libstdc++ with this attribute, - change the warning to apply to all non-marked types, with an extra note (possibly restricted to the case of non-trivial types) pointing out this attribute.
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 ecloud changed: What|Removed |Added CC||s at ecloud dot org --- Comment #5 from ecloud --- >From my perspective it looks like https://bugreports.qt.io/browse/QTBUG-53373 is also a case of -Wtautological-compare being too aggressive too; but I'm not an expert on that code, and it might turn out that someone comes up with some solution other than disabling the warning. If a macro exists in order to test something and generate different code depending on the test result, then in any given use case of the macro, we can say that the test inside the macro is a tautology, right? But that shouldn't mean that doing tests inside macros is bad.
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Resolution|--- |FIXED Known to fail|4.9.2, 5.2.1|4.9.3, 5.4.1, 6.1.1 --- Comment #9 from Georg-Johann Lay --- Fixed in 4.9.4, 5.5, 6.2.
[Bug rtl-optimization/71591] SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71591 Jakub Jelinek changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is because when preprocessing the backend isn't initialized, so if -fself-test attempts to run tests that rely on the backend being initialized, it can't really work. pc_rtx is NULL among hundreds of other issues. Trying to initialize the backend just because of -fself-test is weird, I'd say we should just error loudly in toplev::run_self_tests () if (no_backend).
[Bug middle-end/71529] [7 regression][CHKP] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71529 Ilya Enkovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ilya Enkovich --- Fixed
[Bug rtl-optimization/71591] SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71591 --- Comment #2 from Jakub Jelinek --- Created attachment 38732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38732&action=edit gcc7-pr71591.patch Untested patch to do that.
[Bug middle-end/71581] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71581 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r210199.
[Bug c/70477] -Wtautological-compare too aggressive?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez --- (In reply to ecloud from comment #5) > If a macro exists in order to test something and generate different code > depending on the test result, then in any given use case of the macro, we > can say that the test inside the macro is a tautology, right? But that > shouldn't mean that doing tests inside macros is bad. We want to avoid warning for macros in general because of that, and we already avoid some cases. However, GCC can only detect that something comes from a macro if it expands to something for which GCC tracks locations. GCC currently does not track locations for constants (0), variable-uses (x) and some simple expressions that may get folded too early. So if you have !!0 or 0 != 1, GCC right now cannot tell whether this is the result of macro expansion (at the point of warning). It is not likely that the bug will get fixed in the near term, so if you think that you may still want this warning in general, a work-around is to disable this warning for the relevant line using #pragma GCC diagnostic.
[Bug c++/59861] Inconsistent error output format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59861 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- Please, provide a self-contained testcase. From the output that you quoted, it is not clear why the note is printed at all.
[Bug fortran/71592] New: Add some facilities for compile-time check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71592
Bug ID: 71592
Summary: Add some facilities for compile-time check
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: heresy-me at hotmail dot com
Target Milestone: ---
There are many occasion that to do some compile-time check if we need. For
example, I write my own sqrt function that it may check its parameter should
greater than or equal to zero at compile-time when it is compile-time
evaluated. such as:
function mysqrt(r)
real :: mysqrt
$!assert static(r >= 0.0, "radicand is negative.")
real, intent(in) :: r
end function
just normally likes the compiler behavior.
it also may specify like "!$assert dynamic", "!$assert static_dynamic"
So I need not to fix the obivous compile-time until the program debug. Just
because I know that the C/C++ compiler has been added a standard static_assert
or _Static_assert keyword to finish this work, the Ada language also can
specify the function precondition, then why fortran can't?
C/C++:
float mysqrt(float r) {
static_assert(r >= 0.0, "radicand is negative.");
/* ... */
}
Ada:
function mysqrt(r : Float) return Float
with Precondition => (r >= 0.0);
[Bug c++/71593] New: initializing array with mixed constant and variable size results in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71593
Bug ID: 71593
Summary: initializing array with mixed constant and variable
size results in error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: editing101 at aol dot com
Target Milestone: ---
int length=5;
float test[5][len]={};
gives internal compiler error: in make_decl_rtl, at varasm.c:1313
[Bug fortran/71580] Internal compiler error associated with type bound defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71580 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-06-20 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Duplicate of pr70864?
[Bug middle-end/71581] [5/6/7 Regression] ICE on valid code on x86_64-linux-gnu with -Wuninitialized (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71581 --- Comment #3 from Jakub Jelinek --- Created attachment 38733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38733&action=edit gcc7-pr71581.patch Untested fix.
[Bug target/52305] [avr] ICE in avr_print_operand: unknown mode (const_double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52305 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Georg-Johann Lay --- (In reply to Pitchumani from comment #3) > Not re-producible in gcc-7 trunk. Is it valid anymore? Did you try on a 32-bit host? ähhh.. the last remains of need_64bit_hwi have been removed with r210632 and today we assume that HWI is 64 bits at least, i.e. need_64bit_hwint=yes is assumed. Hence the test case should work also on 32-bit hosts without any itches because target long long is always represented as CONST_INT, not as CONST_DOUBLE. Issue closed.
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #6 from David B. Robins --- Created attachment 38734 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38734&action=edit Test case (for gcc/testsuite/g++.dg/inherit)
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #7 from David B. Robins --- I have verified that the pr71571.C test case attached does expose the bug on trunk and that it passes with the above fix. (Note "-O2 -fno-inline" are required to ensure a crash; see earlier comment; in 4.3.1 "-O2" sufficed, either because it did not inline these thunks or used different criteria.)
[Bug fortran/71592] Add some facilities for compile-time check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71592
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
You can't use such static_assert this way in C++, unless the function is
constexpr, nor in C (always), so guess you are proposing something completely
different (like, if this function/subroutine is inlined and the expression is
after inlining/optimizations constant, then see if it is true or false,
otherwise do nothing. So more like
if (__builtin_constant_p (r >= 0.0))
{
if (!(r >= 0.0)) __builtin_warning ("...");
}
Also, !$ already has a specific meaning in OpenMP, so it would be a bad idea to
abuse it.
[Bug c++/71576] [4.9/5/6/7 Regression] ICE on valid C++11 code (with xvalue and bitfield) on x86_64-linux-gnu: in build_target_expr, at cp/tree.c:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71576 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-20 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Summary|ICE on valid C++11 code |[4.9/5/6/7 Regression] ICE |(with xvalue and bitfield) |on valid C++11 code (with |on x86_64-linux-gnu: in |xvalue and bitfield) on |build_target_expr, at |x86_64-linux-gnu: in |cp/tree.c:385 |build_target_expr, at ||cp/tree.c:385 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started most likely with r180944 (r180941 properly rejects it, r180959 already ICEs).
[Bug c/71594] New: ice in maybe_legitimize_operand, at optabs.c:6893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71594 Bug ID: 71594 Summary: ice in maybe_legitimize_operand, at optabs.c:6893 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 38735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38735&action=edit C source code The attached code, when compiled with flags -c -O3 -march=native on x86_64 by gcc trunk dated 20160619, does this: bug295.c: In function ‘func_0’: bug295.c:9100:1: internal compiler error: in maybe_legitimize_operand, at optabs.c:6893 } ^ 0xb2ab3b maybe_legitimize_operand ../../src/trunk/gcc/optabs.c:6892 0xb3442c maybe_legitimize_operands(insn_code, unsigned int, unsigned int, expand_operand*) ../../src/trunk/gcc/optabs.c:6959 0xb3442c maybe_gen_insn(insn_code, unsigned int, expand_operand*) ../../src/trunk/gcc/optabs.c:6977 0xb3442c maybe_expand_insn(insn_code, unsigned int, expand_operand*) ../../src/trunk/gcc/optabs.c:7020
[Bug c++/71576] [4.9/5/6/7 Regression] ICE on valid C++11 code (with xvalue and bitfield) on x86_64-linux-gnu: in build_target_expr, at cp/tree.c:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71576 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug c/71594] ice in maybe_legitimize_operand, at optabs.c:6893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71594 David Binderman changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #1 from David Binderman --- svn blame suggest that Richard Sandiford wrote the code which fails. Adding him into the distribution list.
[Bug c/71594] [7 Regression] ice in maybe_legitimize_operand, at optabs.c:6893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71594
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-06-20
CC||trippels at gcc dot gnu.org
Summary|ice in |[7 Regression] ice in
|maybe_legitimize_operand, |maybe_legitimize_operand,
|at optabs.c:6893|at optabs.c:6893
Ever confirmed|0 |1
--- Comment #2 from Markus Trippelsdorf ---
In the future please show us what -march=native expands to.
markus@x4 tmp % cat bug295.i
unsigned short a;
int b, c;
int *d;
void fn1() {
*d = 24;
for (; *d <= 65;) {
unsigned short *e = &a;
b = (a &= 0 <= 0) < (c ?: (*e %= *d));
for (; *d <= 83;)
;
}
}
markus@x4 tmp % gcc -c -O3 -march=amdfam10 bug295.i
bug295.i: In function ‘fn1’:
bug295.i:12:1: internal compiler error: in maybe_legitimize_operand, at
optabs.c:6893
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #8 from Hans-Peter Nilsson --- (In reply to David B. Robins from comment #7) > I have verified that the pr71571.C test case attached does expose the bug on > trunk and that it passes with the above fix. Great, thanks for the report and for your time. I think this will do. > (Note "-O2 -fno-inline" are > required to ensure a crash; see earlier comment; in 4.3.1 "-O2" sufficed, > either because it did not inline these thunks or used different criteria.) For future reference, above I mentioned putting it in gcc/testsuite/g++.dg/torture, not ../inherit, and there no "-O2 -fno-inline" combo would not have been required, as I believe the bug would be exposed in the -O0 iteration. Experience says it is brittle to assume "-O2 -fno-inline" would be all that's "stopping" optimizations.
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #9 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #8) > all that's "stopping" optimizations. Bad choice of words, I meant "all that's needed to stop optimizations from making choices that would not expose the bug".
[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69507 --- Comment #9 from Martin Sebor --- Author: msebor Date: Mon Jun 20 15:46:09 2016 New Revision: 237606 URL: https://gcc.gnu.org/viewcvs?rev=237606&root=gcc&view=rev Log: PR c/69507 - bogus warning: ISO C does not allow __alignof__ (expression) gcc/testsuite/ChangeLog: * gnu89-const-expr-1.c: Avoid diagnosing __alignof__ as not conforming. * gnu90-const-expr-1.c: Same. * gnu99-const-expr-1.c: Same. * gnu99-static-1.c: Same. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/gnu89-const-expr-1.c trunk/gcc/testsuite/gcc.dg/gnu90-const-expr-1.c trunk/gcc/testsuite/gcc.dg/gnu99-const-expr-1.c trunk/gcc/testsuite/gcc.dg/gnu99-static-1.c
[Bug c++/71590] G++ template function initialize with wrong type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71590 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Martin Sebor --- It is true that there is no std::string::operator=(int) but the assignment in 'x = a' resolves to std::string::operator(char). The program is valid.
[Bug tree-optimization/71595] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71595
Bug ID: 71595
Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:704
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-O2 and -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 6.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160620 (experimental) [trunk revision 237587] (GCC)
$
$ gcc-trunk -Os -c small.c
$ gcc-6.1 -O2 -c small.c
$
$ gcc-trunk -O2 -c small.c
small.c: In function ‘fn1’:
small.c:6:1: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:704
fn1 ()
^~~
0xd2e54c check_loop_closed_ssa_use
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:703
0xd31306 check_loop_closed_ssa_stmt
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:719
0xd31306 verify_loop_closed_ssa(bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-manip.c:753
0xd1537e tree_unroll_loops_completely(bool, bool)
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1431
0xd1540a execute
../../gcc-source-trunk/gcc/tree-ssa-loop-ivcanon.c:1537
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.
$
-
volatile int a, e;
int c, d[1][5];
long b;
void
fn1 ()
{
for (; c;)
{
int f = c = 0;
for (; c < 3; c++)
{
c && a;
if (e)
f = 1;
b++;
d[b][b + 1] = 1;
if (f)
break;
}
}
}
[Bug c++/71576] [4.9/5/6/7 Regression] ICE on valid C++11 code (with xvalue and bitfield) on x86_64-linux-gnu: in build_target_expr, at cp/tree.c:385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71576
--- Comment #2 from Jakub Jelinek ---
s/properly/.
Anyway, the thing is that we use
cp_lvalue_kind lvalue = real_lvalue_p (expr);
and test the various clk_* bits from it, but this returns clk_none if
lvalue_kind has clk_class or clk_rvalueref set in it.
In this case, lvalue_kind (expr) is clk_bitfield | clk_class, and if we don't
want to ICE, for the creation of the temporary we need the bitfield type to be
widened to the underlying type.
So perhaps:
if (lvalue & clk_bitfield)
{
expr = convert_bitfield_to_declared_type (expr);
expr = fold_convert (type, expr);
}
should be if (lvalue_kind (expr) & clk_bitfield) instead, or just
unconditional?
What about the other lvalue & clk_* tests a few lines before? Do they mean to
ignore clk_bitfield or clk_packed if clk_class (or clk_rvalueref) is also set?
If not, perhaps real_lvalue_p call should be replaced with lvalue_kind.
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #14 from Martin Sebor --- (In reply to Marc Glisse from comment #13) I would also find it preferable to have the warning issued by default without requiring a special attribute to request it. (The unused warning can suppressed by annotating each unused object with attribute unused. Whether or not the object's ctor has side-effects seems orthogonal to whether the object is actually used.) Please see also bug 71456 and bug 71402 for some additional background and discussion of the pros and cons of the approaches mentioned there.
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #10 from David B. Robins --- My apologies, I saw the example you pointed at was from torture/ but missed/forgot that you had also wanted the new test there. I moved the file to torture and removed -O2 -fno-inline and I didn't get the failure. I did get it when I added back only -fno-inline, which at least no longer depends on a specific optimization level: FAIL: g++.dg/torture/pr71571.C -O2 execution test FAIL: g++.dg/torture/pr71571.C -O3 -g execution test FAIL: g++.dg/torture/pr71571.C -Os execution test FAIL: g++.dg/torture/pr71571.C -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: g++.dg/torture/pr71571.C -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test I also confirmed that it passed in the new location with the "fix to be committed" fix.
[Bug c++/58646] ICE on a multidimensional VLA with an empty initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646 Martin Sebor changed: What|Removed |Added CC||editing101 at aol dot com --- Comment #7 from Martin Sebor --- *** Bug 71593 has been marked as a duplicate of this bug. ***
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 71593, which changed state. Bug 71593 Summary: initializing array with mixed constant and variable size results in error https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71593 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/71593] initializing array with mixed constant and variable size results in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71593 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Last reconfirmed||2016-6-20 CC||msebor at gcc dot gnu.org Blocks||16994 Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- Bug 58646 tracks this problem. *** This bug has been marked as a duplicate of bug 58646 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 [Bug 16994] [meta-bug] VLA and C++
[Bug target/71338] [RL78] mulu instruction not used on G10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71338 --- Comment #4 from DJ Delorie --- Sure, the only dependencies might be on binutils/gdb releases, but they support it and they're independent of gcc releases anyway.
[Bug target/71103] avr-gcc crashes with unrecognizable insn error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71103 Georg-Johann Lay changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Georg-Johann Lay --- Unfortunately there are now cases where the subregs pop up during reload and hence copy_to_mode_reg is prohibited like with strftime from avr-libc :-( There are already insns that assume that subregs of constants work to some degree like xload8_A and xload_A. Maybe we'll have to support subregs of constants in their own right...
[Bug c++/71570] [6/7 regression] ICE on invalid variable capture in cxx_incomplete_type_diagnostic, at cp/typeck2.c:551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71570 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-20 CC||jason at gcc dot gnu.org, ||msebor at gcc dot gnu.org Summary|ICE on invalid C++11 code |[6/7 regression] ICE on |(with invalid variable |invalid variable capture in |capture) on |cxx_incomplete_type_diagnos |x86_64-linux-gnu: in|tic, at cp/typeck2.c:551 |cxx_incomplete_type_diagnos | |tic, at cp/typeck2.c:551| Ever confirmed|0 |1 Known to fail||6.1.0, 7.0 --- Comment #1 from Martin Sebor --- The ICE was introduced into GCC 6.0 in r232436: r232436 | jason | 2016-01-15 10:57:07 -0500 (Fri, 15 Jan 2016) | 6 lines PR c++/69257 * typeck.c (decay_conversion): Don't call mark_rvalue_use for array/function-to-pointer conversion. Call complete_type_or_maybe_complain for lvalue-to-rvalue conversion. * call.c (convert_like_real): Print call context if decay_conversion errors.
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #11 from Hans-Peter Nilsson --- (In reply to David B. Robins from comment #10) > My apologies, I saw the example you pointed at was from torture/ but > missed/forgot that you had also wanted the new test there. I moved the file > to torture and removed -O2 -fno-inline and I didn't get the failure. I did > get it when I added back only -fno-inline, which at least no longer depends > on a specific optimization level: Ok, good. Weird that you don't get it for -O0 but never mind. Since you verified that it works there I think, I'll put it in torture/ hoping I won't forget to remove the "-O2 -fno-inline". :) Just one more question; credits where credits are due: are you ok with me putting your name and email address, as it appears in here in bugzilla, on the entry in the testsuite ChangeLog?
[Bug rtl-optimization/71596] New: gcc bootstrap fails due to segv in genrecog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71596 Bug ID: 71596 Summary: gcc bootstrap fails due to segv in genrecog Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: saguryev.gnu at gmail dot com Target Milestone: ---
[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71596 Markus Trippelsdorf changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2016-06-20 CC||trippels at gcc dot gnu.org Summary|gcc bootstrap fails due to |[7 Regression] gcc |segv in genrecog|bootstrap fails due to segv ||in genrecog Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Starting program: /home/trippels/gcc_build_dir_/gcc/build/genrecog ../../gcc/gcc/common.md ../../gcc/gcc/config/i386/i386.md insn-conditions.md >| tmp-recog.c Statistics for recog: Number of decisions: 39371 longest path: 369 (code: 3694) longest backtrack: 24 (code: 4408) Statistics for split_insns: Number of decisions: 2415 longest path:74 (code:389) longest backtrack: 16 (code:400) Statistics for peephole2_insns: Number of decisions: 1387 longest path: 195 (code: 77) longest backtrack: 17 (code:156) Program received signal SIGSEGV, Segmentation fault. 0x0041351d in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () (gdb) bt #0 0x0041351d in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () #1 0x00414504 in init_pattern_use(create_pattern_info*, merge_state_info*, vec const&) () #2 0x00413922 in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () #3 0x004137c9 in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () #4 0x004137c9 in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () #5 0x004137c9 in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () #6 0x004137c9 in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () #7 0x004137c9 in populate_pattern_routine(create_pattern_info*, merge_state_info*, state*, vec const&) () #8 0x00414504 in init_pattern_use(create_pattern_info*, merge_state_info*, vec const&) () #9 0x004046e1 in main ()
[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71596 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |7.0
[Bug c/71597] New: Confusing warning for incompatible enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71597
Bug ID: 71597
Summary: Confusing warning for incompatible enums
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Source code:
--
enum { a } x; // (1)
unsigned x; // (2)
enum { b } x; // (3)
int main()
{
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
test.c:3:12: error: conflicting types for ‘x’
enum { b } x; // (3)
^
test.c:2:10: note: previous declaration of ‘x’ was here
unsigned x; // (2)
^
--
gcc version: gcc (GCC) 7.0.0 20160616 (experimental)
It would be better to display the conflicting declaration (1) instead of just
the previous one (2).
[Bug c/71598] New: Wrong optimization with aliasing enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598
Bug ID: 71598
Summary: Wrong optimization with aliasing enums
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Source code:
--
extern void abort (void);
enum e1 { c1 };
enum e2 { c2 };
__attribute__((noinline,noclone))
int f(enum e1 *p, enum e2 *q)
{
*p = 1;
*q = 2;
return *p;
}
int main()
{
unsigned x;
if (f(&x, &x) != 2)
abort();
}
--
Results:
--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
Aborted
--
gcc version: gcc (GCC) 7.0.0 20160616 (experimental)
In gcc such enums are compatible with unsigned int. Hence they could alias. But
gcc seem to (wrongly) assume that *p and *q cannot refer to the same object.
[Bug rtl-optimization/71596] [7 Regression] gcc bootstrap fails due to segv in genrecog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71596 --- Comment #2 from Sergey --- ( may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70902 ? ) - genrecog crashes with segv if built with gcc@r235523 and later after emitting first 32k of its output -- stack trace below; - it's genrecog.c:init_pattern_use() which is compiled incorrectly at -O2; if compiled at -O1 ( with all others remaining at -O2 ), the problem vanishes; - also, the problem shows up with -march= nehalem, sandybridge and newer archs; if built with -march=nocona or silvermont, it works fine. build/genrecog ../../gcc/gcc/common.md ../../gcc/gcc/config/i386/i386.md insn-conditions.md /* Generated automatically by the program `genrecog' from the target . longest path: 195 (code: 77) longest backtrack: 17 (code:156) Program received signal SIGSEGV, Segmentation fault. populate_pattern_routine (cpi=cpi@entry=0x7fffd980, sinfo=0x4387040, news=news@entry=0x4387090, params=...) at ../../gcc/gcc/genrecog.c:2842 2842 decision *d = sinfo->s->singleton (); (gdb) p sinfo->s $3 = (state *) 0x0 (gdb) bt #0 populate_pattern_routine (cpi=cpi@entry=0x7fffd980, sinfo=0x4387040, news=news@entry=0x4387090, params=...) at ../../gcc/gcc/genrecog.c:2842 #1 0x004175e5 in populate_pattern_routine (cpi=cpi@entry=0x7fffd980, sinfo=0x77208ee0, news=, params=...) at ../../gcc/gcc/genrecog.c:2907 #2 0x00417a91 in init_pattern_use (cpi=cpi@entry=0x7fffd980, sinfo=0x77208ee0, params=...) at ../../gcc/gcc/genrecog.c:2788 #3 0x0041728f in populate_pattern_routine (cpi=cpi@entry=0x7fffe190, sinfo=0x771f7348, news=news@entry=0x4386b10, params=...) at ../../gcc/gcc/genrecog.c:2912 #4 0x004175e5 in populate_pattern_routine (cpi=cpi@entry=0x7fffe190, sinfo=0x771e9fe0, news=news@entry=0x4386aa0, params=...) at ../../gcc/gcc/genrecog.c:2907 #5 0x004175e5 in populate_pattern_routine (cpi=cpi@entry=0x7fffe190, sinfo=0x771e0d78, news=news@entry=0x4386a30, params=...) at ../../gcc/gcc/genrecog.c:2907 #6 0x004175e5 in populate_pattern_routine (cpi=cpi@entry=0x7fffe190, sinfo=0x771da6f8, news=news@entry=0x43869c0, params=...) at ../../gcc/gcc/genrecog.c:2907 #7 0x004175e5 in populate_pattern_routine (cpi=cpi@entry=0x7fffe190, sinfo=0x771d7520, news=news@entry=0x4386950, params=...) at ../../gcc/gcc/genrecog.c:2907 #8 0x004175e5 in populate_pattern_routine (cpi=cpi@entry=0x7fffe190, sinfo=0x771d5608, news=, params=...) at ../../gcc/gcc/genrecog.c:2907 #9 0x00417a91 in init_pattern_use (cpi=cpi@entry=0x7fffe190, sinfo=sinfo@entry=0x771d5608, params=...) at ../../gcc/gcc/genrecog.c:2788 #10 0x004034e1 in use_pattern (sinfo=) at ../../gcc/gcc/genrecog.c:2993 #11 split_out_patterns (states=...) at ../../gcc/gcc/genrecog.c:3243 #12 main (argc=, argv=) at ../../gcc/gcc/genrecog.c:5317
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #12 from David B. Robins --- Note that it does still need -fno-inline. I know why it doesn't crash with -O0: there is a text-section constant inserted after the thunk, and it's inlined at higher optimization levels. The instruction said constant maps to is either harmless or forbidden as a delay slot instruction. So the underlying issue still occurs but the crash doesn't. At higher optimization levels the function is also inlined in the thunk (that didn't happen on 4.3.1). This also seems somewhat fragile - the crash is dependent on what's next in the generated code - which is why I wasn't sure about what sort of test to add. I am OK with my name/email being included in the ChangeLog, thank you.
[Bug fortran/71194] ICE on compilation with fcheck=all ; -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71194 --- Comment #2 from Tobias Burnus --- Author: burnus Date: Mon Jun 20 18:46:43 2016 New Revision: 237612 URL: https://gcc.gnu.org/viewcvs?rev=237612&root=gcc&view=rev Log: 2016-06-20 Tobias Burnus fortran/71194 * trans-expr.c (gfc_trans_pointer_assignment): Correctly handle RHS pointer functions. 2016-06-20 Tobias Burnus PR fortran/71194 * gfortran.dg/pointer_remapping_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/pointer_remapping_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/71599] New: An extra unrelated move when compiling compare_exchange_strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71599
Bug ID: 71599
Summary: An extra unrelated move when compiling
compare_exchange_strong
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jianjin2016 at fb dot com
Target Milestone: ---
At high optimizations, for the code below:
bool cas(std::atomic* target, uint64_t expected, uint64_t desired) {
return target->compare_exchange_strong(expected, desired);
}
Gcc gives (link: https://godbolt.org/g/wP8Ah8 ):
movq %rsi, %rax
movq %rsi, -8(%rsp) ---(Note this spurious move)
lock cmpxchgq %rdx, (%rdi)
sete %al
ret
However,
Clang gives (link: https://godbolt.org/g/UmUO7M ):
movq %rsi, %rax
lock cmpxchgq %rdx, (%rdi)
sete %al
retq
This extra and unrelated move will make a difference in our measurable
benchmark result.
[Bug rtl-optimization/65628] valgrind error in improve_allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65628 David Binderman changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME |--- --- Comment #5 from David Binderman --- >David, in the future please use an --enable-checking=valgrind compiler >for valgrind testing. Righto. I tried a build of today's (20160620) gcc trunk with this flag you recommend. I got ==16199== Conditional jump or move depends on uninitialised value(s) ==16199==at 0x89001C: improve_allocation() (ira-color.c:2809) ==16199==by 0x893F3E: color_allocnos (ira-color.c:3140) ==16199==by 0x893F3E: color_pass(ira_loop_tree_node*) (ira-color.c:3249) ==16199==by 0x87D136: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1780) Source code is if ((hregno = ALLOCNO_HARD_REGNO (a)) < 0) So it looks to me like the problem is still there. Configure line is ../src/trunk/configure --prefix=/home/dcb/gcc/results \ --disable-bootstrap \ --disable-multilib \ --disable-werror \ --enable-checking=valgrind \ --enable-languages=c,c++,fortran And it looks like -O3 needs to be switched on in the build. At the top level Makefile: sed 's/-O2/-O3 -march=native -Wall -Wlogical-op/' < Makefile > Makefile.tmp mv Makefile.tmp Makefile Although I guess make target bootstrap-O3 would also provoke this valgrind error.
[Bug target/71559] ICE in ix86_fp_cmp_code_to_pcmp_immediate, at config/i386/i386.c:23042 (KNL/AVX512)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71559 --- Comment #19 from Jakub Jelinek --- Author: jakub Date: Mon Jun 20 19:17:12 2016 New Revision: 237614 URL: https://gcc.gnu.org/viewcvs?rev=237614&root=gcc&view=rev Log: PR target/71559 * config/i386/i386.c (ix86_fp_cmp_code_to_pcmp_immediate): Fix up returned values and add UN*/LTGT/*ORDERED cases with values matching D operand modifier on vcmp for AVX. * gcc.target/i386/sse2-pr71559.c: New test. * gcc.target/i386/avx-pr71559.c: New test. * gcc.target/i386/avx512f-pr71559.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx-pr71559.c trunk/gcc/testsuite/gcc.target/i386/avx512f-pr71559.c trunk/gcc/testsuite/gcc.target/i386/sse2-pr71559.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/70825] x86_64: __atomic_compare_exchange_n() accesses stack unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70825 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 66867. *** This bug has been marked as a duplicate of bug 66867 ***
[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867 Andrew Pinski changed: What|Removed |Added CC||dhowells at redhat dot com --- Comment #4 from Andrew Pinski --- *** Bug 70825 has been marked as a duplicate of this bug. ***
[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867 Andrew Pinski changed: What|Removed |Added CC||jianjin2016 at fb dot com --- Comment #6 from Andrew Pinski --- *** Bug 71599 has been marked as a duplicate of this bug. ***
[Bug middle-end/66867] Suboptimal code generation for atomic_compare_exchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66867 Andrew Pinski changed: What|Removed |Added CC||tkoeppe at google dot com --- Comment #5 from Andrew Pinski --- *** Bug 66713 has been marked as a duplicate of this bug. ***
[Bug middle-end/66713] atomic compare_exchange_strong creates spurious store for x86-64 at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66713 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 66867. *** This bug has been marked as a duplicate of bug 66867 ***
[Bug c++/71599] An extra unrelated move when compiling compare_exchange_strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71599 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 66867. *** This bug has been marked as a duplicate of bug 66867 ***
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 Hans-Peter Nilsson changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c/71600] New: [7 regression] test case gcc.dg/gnu89-const-expr-1.c fails starting with r237581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71600
Bug ID: 71600
Summary: [7 regression] test case gcc.dg/gnu89-const-expr-1.c
fails starting with r237581
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at linux dot vnet.ibm.com
Target Milestone: ---
FAIL: gcc.dg/gnu89-const-expr-1.c (test for errors, line 26)
line 26:
E7 = __alignof__ (a), /* { dg-error "__alignof__ \\(expression\\)" } */
This revision changed things so the __alignof__ expression is now valid. If
that is correct then this test case needs to be updated.
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #13 from Hans-Peter Nilsson --- Author: hp Date: Mon Jun 20 20:01:20 2016 New Revision: 237615 URL: https://gcc.gnu.org/viewcvs?rev=237615&root=gcc&view=rev Log: PR target/71571 * config/cris/cris.c (cris_asm_output_mi_thunk): Add missing "ba" delay-slot "nop" for PIC with CRIS v32. Also add missing leading space for PIC with non-v32 and the common non-PIC "jump". Modified: trunk/gcc/ChangeLog trunk/gcc/config/cris/cris.c
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571
--- Comment #14 from Hans-Peter Nilsson ---
Author: hp
Date: Mon Jun 20 20:02:03 2016
New Revision: 237616
URL: https://gcc.gnu.org/viewcvs?rev=237616&root=gcc&view=rev
Log:
PR target/71571
* g++.dg/torture/pr71571.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/torture/pr71571.C (with props)
Modified:
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/g++.dg/torture/pr71571.C
('svn:executable' added)
[Bug c/71600] [7 regression] test case gcc.dg/gnu89-const-expr-1.c fails starting with r237581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71600
--- Comment #1 from Bill Seurer ---
Also this test case:
FAIL: gcc.dg/gnu99-static-1.c (test for errors, line 14)
line 14:
void g0(void) { __alignof__(f0()); } /* { dg-error "__alignof__
\\(expression\\)" } */
[Bug libstdc++/71181] Reserving in unordered_map doesn't reserve enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71181 --- Comment #5 from François Dumont --- Author: fdumont Date: Mon Jun 20 20:04:25 2016 New Revision: 237617 URL: https://gcc.gnu.org/viewcvs?rev=237617&root=gcc&view=rev Log: 2016-06-20 François Dumont PR libstdc++/71181 * include/tr1/hashtable_policy.h (_Prime_rehash_policy::_M_next_bkt): Make past-the-end iterator dereferenceable to avoid check on lower_bound result. (_Prime_rehash_policy::_M_bkt_for_elements): Call latter. (_Prime_rehash_policy::_M_need_rehash): Likewise. * src/c++11/hashtable_c++0x.cc (_Prime_rehash_policy::_M_next_bkt): Always return a value greater than input value. Set _M_next_resize to max value when reaching highest prime number. * src/shared/hashtable-aux.cc (__prime_list): Add comment about sentinel being now useless. * testsuite/23_containers/unordered_set/hash_policy/71181.cc: New. * testsuite/23_containers/unordered_set/hash_policy/power2_rehash.cc (test02): New. * testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc: New. * testsuite/23_containers/unordered_set/hash_policy/rehash.cc: Fix indentation. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/71181.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/prime_rehash.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1/hashtable_policy.h trunk/libstdc++-v3/src/c++11/hashtable_c++0x.cc trunk/libstdc++-v3/src/shared/hashtable-aux.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/power2_rehash.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_set/hash_policy/rehash.cc
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 Hans-Peter Nilsson changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c/71600] [7 regression] test case gcc.dg/gnu89-const-expr-1.c fails starting with r237581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71600 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Sebor --- Thank you. I fixed this earlier today in r237606: https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01426.html
[Bug target/71571] [CRIS] Multiple inheritance non-virtual PIC thunk causes crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71571 --- Comment #15 from Hans-Peter Nilsson --- (In reply to David B. Robins from comment #12) > Note that it does still need -fno-inline. I almost missed. > I know why it doesn't crash with -O0: there is a text-section constant > inserted after the thunk, and it's inlined at higher optimization levels. > The instruction said constant maps to is either harmless or forbidden as a > delay slot instruction. So the underlying issue still occurs but the crash > doesn't. Ah, ok, thanks for the analysis. > I am OK with my name/email being included in the ChangeLog, thank you. Great. BTW, I'm keeping the PR open, pending back-ports to open branches. Thanks again!
[Bug c/71601] New: ICE on conditional expression between DFP / non-DFP float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71601
Bug ID: 71601
Summary: ICE on conditional expression between DFP / non-DFP
float
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
Target Milestone: ---
A conditional expression between DFP and non-DFP floating-point produces an
ICE:
_Decimal32 a;
float b;
int i;
void
f (void)
{
(void) (i ? a : b);
}
(on x86_64-pc-linux-gnu):
t.c: In function 'f':
t.c:7:3: error: can't mix operands of decimal float and other float types
(void) (i ? a : b);
^
t.c:7:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in get_qualified_type, at tree.c:6604
0xdbe161 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.c:9803
0xdd4161 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.h:3153
0xdd4161 get_qualified_type(tree_node*, int)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.c:6604
0xddb0ed build_qualified_type(tree_node*, int)
/scratch/jmyers/fsf/gcc-mainline/gcc/tree.c:6626
0x5ffe7a build_conditional_expr(unsigned int, tree_node*, bool, tree_node*,
tree_node*, tree_node*, tree_node*)
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-typeck.c:5028
0x629514 c_parser_conditional_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6411
0x629970 c_parser_expr_no_commas
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6268
0x62a0d2 c_parser_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:8464
0x624942 c_parser_postfix_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:7595
0x62760a c_parser_unary_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6939
0x6283b7 c_parser_cast_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6771
0x62845f c_parser_cast_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6760
0x6285d2 c_parser_binary_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6580
0x6292b5 c_parser_conditional_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6351
0x629970 c_parser_expr_no_commas
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:6268
0x62a0d2 c_parser_expression
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:8464
0x62ab19 c_parser_expression_conv
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:8497
0x64382c c_parser_statement_after_labels
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:5287
0x645968 c_parser_compound_statement_nostart
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:4861
0x645cde c_parser_compound_statement
/scratch/jmyers/fsf/gcc-mainline/gcc/c/c-parser.c:4696
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
I don't know if there was any version where this did not produce an ICE.
Testing a patch.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
--- Comment #15 from Howard Hinnant ---
To help clarify my proposal, here is a patch:
diff --git a/libstdc++-v3/src/c++11/thread.cc
b/libstdc++-v3/src/c++11/thread.cc
index 906cafa..cfca178 100644
--- a/libstdc++-v3/src/c++11/thread.cc
+++ b/libstdc++-v3/src/c++11/thread.cc
@@ -79,19 +79,7 @@ namespace std _GLIBCXX_VISIBILITY(default)
thread::__shared_base_type __local;
__local.swap(__t->_M_this_ptr);
- __try
- {
- __t->_M_run();
- }
- __catch(const __cxxabiv1::__forced_unwind&)
- {
- __throw_exception_again;
- }
- __catch(...)
- {
- std::terminate();
- }
-
+ __t->_M_run();
return nullptr;
}
}
My colleague Miguel Portilla has tested this patch with the following code:
#include
#include
void a(int i);
void b(int i);
void c(int i);
int
main()
{
auto t = std::thread{a, 3};
t.join();
}
void
a(int i)
{
b(i-1);
}
void
b(int i)
{
c(i-1);
}
void
c(int i)
{
throw std::runtime_error("A good message");
}
And the stack dump looks like:
Thread 2 (Thread 0x7f090b47c740 (LWP 1865)):
#0 0x7f090b0688ed in pthread_join (threadid=139676803389184,
thread_return=0x0) at pthread_join.c:90
#1 0x7f090ad9c767 in __gthread_join (__value_ptr=0x0,
__threadid=)
at
/home/mickey/gcc-5.4.0/build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu/bits/gthr-default.h:668
#2 std::thread::join (this=0x7ffd1dae6430) at
../../../../../libstdc++-v3/src/c++11/thread.cc:96
#3 0x00400f39 in main ()
Thread 1 (Thread 0x7f090a3fd700 (LWP 1866)):
#0 0x7f090a433267 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:55
#1 0x7f090a434eca in __GI_abort () at abort.c:89
#2 0x7f090ad747dd in __gnu_cxx::__verbose_terminate_handler ()
at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x7f090ad72866 in __cxxabiv1::__terminate (handler=)
at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x7f090ad728b1 in std::terminate () at
../../../../libstdc++-v3/libsupc++/eh_terminate.cc:57
#5 0x7f090ad72ac8 in __cxxabiv1::__cxa_throw (obj=0x7f0904000940,
tinfo=0x604360 ,
dest=0x400ce0 ) at
../../../../libstdc++-v3/libsupc++/eh_throw.cc:87
#6 0x00400fdd in c(int) ()
#7 0x00400fa0 in b(int) ()
#8 0x00400f85 in a(int) ()
#9 0x00402574 in void std::_Bind_simple::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
#10 0x00402493 in std::_Bind_simple::operator()()
()
#11 0x00402432 in std::thread::_Impl >::_M_run() ()
#12 0x7f090ad9c820 in std::execute_native_thread_routine (__p=)
at ../../../../../libstdc++-v3/src/c++11/thread.cc:82
#13 0x7f090b0676aa in start_thread (arg=0x7f090a3fd700) at
pthread_create.c:333
#14 0x7f090a504e9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
