[Bug tree-optimization/66652] try_transform_to_exit_first_loop_alt generates incorrect loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66652 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org --- Comment #6 from vries at gcc dot gnu.org --- Patch with test-case committed to trunk, marking resolved-fixed.
[Bug c++/66701] New: __cxxabiv1::__cxa_pure_virtual - can it take an argument of the pointer to the function that was called, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66701
Bug ID: 66701
Summary: __cxxabiv1::__cxa_pure_virtual - can it take an
argument of the pointer to the function that was
called, please?
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jmcguiness at liquidcapital dot com
Target Milestone: ---
I am aware of the ability to modify the handler for the pure virtual function
called error message via something like:
namespace __cxxabiv1 {
extern C void
__cxa_pure_virtual(void) {
// Print a backtrace, etc...
std::terminate();
}
}
It is a great shame that the default, gcc-supplied function declaration does
not take an argument of the function pointer that was called, then the RTTI
information could be output. Note that the error message comes from a pure
virtual base class on which a pure virtual function has been called. Therefore
one would suppose that the was guaranteed to be RTTI information regarding that
function call, if not the enclosing pure virtual base class. So the default
implementation of __cxa_pure_virtual() would be able to call
typeid(ptr_to_mem_fn).name() to provide actual type information regarding the
class and the function that was attempted to be called.
I realise that the declaration could be difficult, because the new argument to
__cxa_pure_virtual(...) would need to be able to cope with both void and
non-void return types, cv-qualifiers, and arbitrary arguments. i.e. it would
need some form of declaration magic. But the code is within the compiler! At
the call site where the canary is being placed, the type of the member function
is explicitly known, so the specific declaration (in particular the
ptr-to-mem-fn argument) of __cxa_pure_virtual() can be generated for that call
site, and therefore typeid(of the ptr-to-mem-fn arg) could be correctly
generated.
If I knew how g++ worked internally, I'd do this change. But I don't, I'm
sorry.
The issue I face is that I have a multi-threaded program that has a race
condition that causes the pure virtual function call error very rarely. The
code-base is very large, so it is very hard (I have tried) to track down where
the bug is. It does not appear in debug builds (-O0) and using my own
implementation of __cxa_pure_virtual() and calling set_terminate with my own
functions that generate backtraces has not created the backtrace I'd hope for.
I know also that the code I am referring to above is buggy, therefore I should
just not write it. True. But surely improving the quality of the error
message with the class name and function name in the pure virtual method
called message would be og much help to the C++ community at large?
[Bug tree-optimization/66678] loop counter not accurately described by vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66678 --- Comment #2 from vries at gcc dot gnu.org --- Created attachment 35878 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35878action=edit tentative patch
[Bug tree-optimization/66652] try_transform_to_exit_first_loop_alt generates incorrect loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66652 --- Comment #5 from vries at gcc dot gnu.org --- Author: vries Date: Tue Jun 30 08:35:57 2015 New Revision: 225162 URL: https://gcc.gnu.org/viewcvs?rev=225162root=gccview=rev Log: Use max_loop_iterations in transform_to_exit_first_loop_alt 2015-06-30 Tom de Vries t...@codesourcery.com PR tree-optimization/66652 * tree-parloops.c (try_transform_to_exit_first_loop_alt): Use max_loop_iterations to determine if nit + 1 overflows. * testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c (f): Rewrite using restrict pointers. (main): Add arguments to calls to f. * testsuite/libgomp.c/parloops-exit-first-loop-alt.c: Same. * gcc.dg/parloops-exit-first-loop-alt-pr66652.c: New test. * gcc.dg/parloops-exit-first-loop-alt-3.c (f): Rewrite using restrict pointers. * gcc.dg/parloops-exit-first-loop-alt.c: Same. Added: trunk/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-pr66652.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-3.c trunk/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt.c trunk/gcc/tree-parloops.c trunk/libgomp/ChangeLog trunk/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c trunk/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt.c
[Bug tree-optimization/66678] loop counter not accurately described by vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66678 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to vries from comment #2) Created attachment 35878 [details] tentative patch That single-use case is awfully special ... just add an unrelated use to the function and we no longer optimize again. The real issue with VRP is that given an assert-expr we have no chance to record multiple ranges via equivalences because equivalences are still tied to SSA defs. The same issue pops up for other cases. So instead of hacking in single-use special-casing we should rather fix that deficiency... A possible different way to represent equivalences is to not tie value-ranges directly to SSA names (by indexing the array with their SSA_NAME_VERSION) but instead introduce an indirection and thus allow arbitrary new value-ranges to be stored. So instead of static value_range_t **vr_value; have vecvalue_range_t values; static unsigned *vr_value; and thus get_value_range doing unsigned ver = SSA_NAME_VERSION (var); return values[vr_value[ver]]; and make equivalences a bitmap of indexes into 'values' instead of SSA_NAME_VERSIONs. Then you can always record both ranges from the assert (thus keep both the symbolic and a constant range when you now have to decide for one)
[Bug target/64833] [SH]: Error: pcrel too far when compiling imagemagick and graphicsmagick on Debian sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833 --- Comment #21 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Wed Jul 1 01:02:48 2015 New Revision: 225219 URL: https://gcc.gnu.org/viewcvs?rev=225219root=gccview=rev Log: PR target/64833 * [SH] Set length of casesi_worker_1 insn to 8 when flag_pic is set. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug c++/66701] __cxxabiv1::__cxa_pure_virtual - can it take an argument of the pointer to the function that was called, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66701 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- But this isn't the place to propose changes to the ABI, because it's used by several different compilers and if G++ started emitting a call to a different version of __cxa_pure_virtual that would break compatibility with other compilers using the same ABI. So this is not something that can be added to GCC unless it is first added to the ABI.
[Bug c/66618] Failure to diagnose non-constant initializer for static object with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618 --- Comment #3 from Keith Thompson Keith.S.Thompson at gmail dot com --- It would be easier to argue that gcc accepts other forms of constant expressions if (a) those other forms were documented and (b) they were accepted at all optimization levels. Admittedly the standard doesn't seem to require such documentation (which I find a little surprising), and you could argue that gcc -O0 and gcc -O1 are two different implementations.
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #7 from Patrick Palka ppalka at gcc dot gnu.org --- Author: ppalka Date: Wed Jul 1 01:07:35 2015 New Revision: 225220 URL: https://gcc.gnu.org/viewcvs?rev=225220root=gccview=rev Log: Fix PR c++/66686 (dependent template template substitution) gcc/cp/ChangeLog: PR c++/66686 * pt.c (coerce_template_template_parm) [PARM_DECL]: Don't return 0 if tsubst returns a dependent type. gcc/testsuite/ChangeLog: PR c++/66686 * g++.dg/template/pr66686.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr66686.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #41 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Kazumoto Kojima from comment #40) with my 4.9 native compiler built with 4.9 cross compiler for svn gcc-4_9-branch. I hope that miscompilation for mpfr is gone for bootstrapped 4.9 compiler and it fixes the original gcc issue too. Matthias, Adrian, what about the original error? I cannot test yet as I have to fix the buildds first. This miscompilation issue seems to have affected a couple of packages that found their way into the build roots now and are causing me headaches. I am waiting for Matthias to upload a new gcc-4.9 snapshot in the following days while I will use the time to fix the build roots, then have the buildds build the latest gcc-4.9 package and finally reschedule as many as possible affected packages for rebuild. So, please bear with me until I can give some feedback. Adrian
[Bug target/66703] New: [4.9] gcc.target/i386/readeflags-1.c aborts on -march=i586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66703 Bug ID: 66703 Summary: [4.9] gcc.target/i386/readeflags-1.c aborts on -march=i586 Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: julia.koval at intel dot com Target Milestone: --- Reproduce: $ gcc ../../gcc/testsuite/gcc.target/i386/readeflags-1.c -O0 -m32 -march=i586 -lm $ ./a.out Aborted (core dumped) Carry flag is reset in andl instruction in readeflags_test function.
[Bug middle-end/66702] #pragma omp declare simd uniform and linear issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66702 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jun 30 12:16:01 2015 New Revision: 225180 URL: https://gcc.gnu.org/viewcvs?rev=225180root=gccview=rev Log: PR middle-end/66702 * omp-low.c (simd_clone_adjust): Handle addressable linear or uniform parameters or non-gimple type uniform parameters. * testsuite/libgomp.c++/pr66702-1.C: New test. * testsuite/libgomp.c++/pr66702-2.C: New test. Added: branches/gcc-5-branch/libgomp/testsuite/libgomp.c++/pr66702-1.C branches/gcc-5-branch/libgomp/testsuite/libgomp.c++/pr66702-2.C Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/omp-low.c branches/gcc-5-branch/libgomp/ChangeLog
[Bug tree-optimization/66704] [6 Regression] ICE in tree-vectorizer at tree-ssanames.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66704 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 30 12:52:55 2015 New Revision: 225182 URL: https://gcc.gnu.org/viewcvs?rev=225182root=gccview=rev Log: 2015-06-30 Richard Biener rguent...@suse.de PR tree-optimization/66704 * tree-vect-data-refs.c (vect_setup_realignment): Use make_ssa_name for non-SSA name source. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/66704] [6 Regression] ICE in tree-vectorizer at tree-ssanames.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66704 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/66702] #pragma omp declare simd uniform and linear issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66702 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jun 30 12:12:42 2015 New Revision: 225179 URL: https://gcc.gnu.org/viewcvs?rev=225179root=gccview=rev Log: PR middle-end/66702 * omp-low.c (simd_clone_adjust): Handle addressable linear or uniform parameters or non-gimple type uniform parameters. * testsuite/libgomp.c++/pr66702-1.C: New test. * testsuite/libgomp.c++/pr66702-2.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr66702-1.C trunk/libgomp/testsuite/libgomp.c++/pr66702-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog
[Bug tree-optimization/66704] [6 Regression] ICE in tree-vectorizer at tree-ssanames.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66704 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Index: gcc/tree-vect-data-refs.c === --- gcc/tree-vect-data-refs.c (revision 225163) +++ gcc/tree-vect-data-refs.c (working copy) @@ -4857,7 +4857,10 @@ vect_setup_realignment (gimple stmt, gim ptr = vect_create_data_ref_ptr (stmt, vectype, loop_for_initial_load, NULL_TREE, init_addr, NULL, inc, true, inv_p); - new_temp = copy_ssa_name (ptr); + if (TREE_CODE (ptr) == SSA_NAME) + new_temp = copy_ssa_name (ptr); + else + new_temp = make_ssa_name (TREE_TYPE (ptr)); new_stmt = gimple_build_assign (new_temp, BIT_AND_EXPR, ptr, build_int_cst (TREE_TYPE (ptr), should fix it.
[Bug tree-optimization/66704] New: [6 Regression] ICE in tree-vectorizer at tree-ssanames.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66704 Bug ID: 66704 Summary: [6 Regression] ICE in tree-vectorizer at tree-ssanames.c:457 Product: gcc Version: 6.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: --- Hello. Starting from r224514, there's a new issue spotted on ppc64le: ./xgcc -B. ../../gcc/testsuite/gcc.target/powerpc/pr60137.c -mcpu=power8 -O3 -c -mno-vsx ../../gcc/testsuite/gcc.target/powerpc/pr60137.c:13:6: internal compiler error: tree check: expected ssa_name, have addr_expr in copy_ssa_name_fn, at tree-ssanames.c:457 void init_reg_sets_1(void) ^ 0x4f8b tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9379 0x102748ab tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:2858 0x11029a4f copy_ssa_name_fn(function*, tree_node*, gimple_statement_base*) ../../gcc/tree-ssanames.c:457 0x116685cf copy_ssa_name ../../gcc/tree-ssanames.h:116 0x11677963 vect_setup_realignment(gimple_statement_base*, gimple_stmt_iterator*, tree_node**, dr_alignment_support, tree_node*, loop**) ../../gcc/tree-vect-data-refs.c:4854 0x1106dd77 vectorizable_load ../../gcc/tree-vect-stmts.c:6548 0x11071717 vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) ../../gcc/tree-vect-stmts.c:7506 0x1108d0ab vect_transform_loop(_loop_vec_info*) ../../gcc/tree-vect-loop.c:6238 0x110ad3a7 vectorize_loops() ../../gcc/tree-vectorizer.c:495 0x10f2046b execute ../../gcc/tree-ssa-loop.c:289 Problem can reproduced on gcc112.fsffrance.org machine. Thanks, Martin
[Bug middle-end/66702] #pragma omp declare simd uniform and linear issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66702 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.2 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 5.2+.
[Bug ipa/66705] New: [5/6 Regression] section is missing linker error with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66705 Bug ID: 66705 Summary: [5/6 Regression] section is missing linker error with -flto -fipa-pta Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- For example: markus@x4 ~ % g++ -O2 -flto -fipa-pta -w tramp3d-v4.cpp lto1: fatal error: /tmp/ccIP6ytn.ltrans0.o: section _ZTVN6Smarts8RunnableE is missing compilation terminated. lto-wrapper: fatal error: /usr/x86_64-pc-linux-gnu/gcc-bin/5.1.1/g++ returned 1 exit status compilation terminated. /usr/lib/gcc/x86_64-pc-linux-gnu/5.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status markus@x4 ~ % c++filt _ZTVN6Smarts8RunnableE vtable for Smarts::Runnable Reducing...
[Bug tree-optimization/66704] [6 Regression] ICE in tree-vectorizer at tree-ssanames.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66704 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-30 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine. (seems I missed one spot)
[Bug target/66136] AArch64 geniterators.sh relies on GNU sed syntax, causing build failure on FreeBSD and probably Mac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66136 --- Comment #14 from nsz at gcc dot gnu.org --- Author: nsz Date: Tue Jun 30 10:07:03 2015 New Revision: 225170 URL: https://gcc.gnu.org/viewcvs?rev=225170root=gccview=rev Log: Backport of r224031 from mainline 2015-06-29 Szabolcs Nagy szabolcs.n...@arm.com Backport from mainline: 2015-06-02 Szabolcs Nagy szabolcs.n...@arm.com PR target/66136 * config/aarch64/geniterators.sh: Rewrite in awk. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/aarch64/geniterators.sh
[Bug middle-end/65686] [5/6 regression] inconsistent warning maybe-uninitialized: warn about 'unsigned', not warn about 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65686 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug debug/65779] [5/6 Regression] undefined local symbol on powerpc [regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug debug/65821] [4.9/5/6 regression] incorrect debug line # info for main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|WAITING |NEW Known to work||4.7.2
[Bug ipa/65844] [5/6 Regression] ICE (verify_cgraph_node failed) on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65844 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |WAITING Last reconfirmed||2015-06-30 Component|lto |ipa Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Waiting for a testcase.
[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- So...? Would be nice to fix for 5.2.
[Bug middle-end/65874] [5 Regression] bootstrap comparison failure (gcc/ira.o) on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65874 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Bootstrap also works for me on the GCC 5 branch.
[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65931 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Waiting for apple
[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/66178] [4.9/5/6 Regression] Another label as values ICE in gen_reg_rtx, at emit-rtl.c:1059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66178 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #12 from Antonio Poggiali antonio.poggiali at datalogic dot com --- Created attachment 35879 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35879action=edit Temporary patch for gcc 4.9.3 A temporary patch masking the problem on gcc 4.9.3
[Bug ipa/66705] [5/6 Regression] section is missing linker error with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66705 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- (gdb) p debug_tree (decl) var_decl 0x768d7900 a type integer_type 0x768d0690 int public SI size integer_cst 0x768ccdf8 constant 32 unit size integer_cst 0x768cce10 constant 4 align 32 symtab 0 alias set -1 canonical type 0x768d0690 precision 32 min integer_cst 0x768ccdb0 -2147483648 max integer_cst 0x768ccdc8 2147483647 pointer_to_this pointer_type 0x768e77e0 public external SI file t.ii line 5 col 5 size integer_cst 0x768ccdf8 32 unit size integer_cst 0x768cce10 4 align 32 context translation_unit_decl 0x77ff11e0 D.3949 initial error_mark 0x768ccba0 so it's just a global (in another partition I suppose) ...
[Bug ipa/66705] [5/6 Regression] section is missing linker error with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66705
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
trippels@gcc75 ~ % cat tramp3d-v4.ii
class A {
public:
A();
};
int a = 0;
void foo() {
a = 0;
A b;
for (; a;)
;
}
trippels@gcc75 ~ % g++ -r -nostdlib -O2 -flto -flto-partition=max -fipa-pta
tramp3d-v4.ii
lto1: fatal error: /home/trippels/tmp/cccC3PXI.ltrans0.o: section a is missing
compilation terminated.
[Bug ipa/66705] [5/6 Regression] section is missing linker error with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66705 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-30 Target Milestone|--- |5.2 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Breakpoint 1, fatal_error (loc=0, gmsgid=0x1783549 %s: section %s is missing) at /space/rguenther/src/svn/gcc-5-branch/gcc/diagnostic.c:1203 1203 va_start (ap, gmsgid); Missing separate debuginfos, use: zypper install libgmp10-debuginfo-6.0.0-71.1.x86_64 libisl13-debuginfo-0.14-25.2.x86_64 libmpc3-debuginfo-1.0.2-38.2.x86_64 libmpfr4-debuginfo-3.1.2-3.1.2.x86_64 (gdb) up #1 0x00fe0387 in varpool_node::get_constructor (this=0x76ac4000) at /space/rguenther/src/svn/gcc-5-branch/gcc/varpool.c:328 328 name); (gdb) l 323 data = lto_get_section_data (file_data, LTO_section_function_body, 324name, len); 325 if (!data) 326 fatal_error (input_location, %s: section %s is missing, 327 file_data-file_name, 328 name); (gdb) up #2 0x00eacc07 in create_variable_info_for (decl=0x768d7900, name=0x1763482 NULL) at /space/rguenther/src/svn/gcc-5-branch/gcc/tree-ssa-structalias.c:5808 5808 if (vnode-get_constructor () (gdb) l 5803 if (!vnode-all_refs_explicit_p ()) 5804make_copy_constraint (vi, nonlocal_id); 5805 5806 /* If this is a global variable with an initializer and we are in 5807 IPA mode generate constraints for it. */ 5808 if (vnode-get_constructor () 5809 vnode-definition) so IPA PTA needs to guard -get_constructor () somehow? That is, it doesn't return NULL_TREE when it cant' get its hands on it?
[Bug c++/60364] [[noreturn]] specified for second declaration but not first doesn't result in a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60364 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-30 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug tree-optimization/66652] try_transform_to_exit_first_loop_alt generates incorrect loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66652 --- Comment #7 from vries at gcc dot gnu.org --- Author: vries Date: Tue Jun 30 09:57:20 2015 New Revision: 225166 URL: https://gcc.gnu.org/viewcvs?rev=225166root=gccview=rev Log: Backport transform_to_exit_first_loop_alt-related patches 2015-06-30 Tom de Vries t...@codesourcery.com backport from trunk: 2015-06-30 Tom de Vries t...@codesourcery.com PR tree-optimization/66652 * tree-parloops.c (try_transform_to_exit_first_loop_alt): Use max_loop_iterations to determine if nit + 1 overflows. * testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c (f): Rewrite using restrict pointers. (main): Add arguments to calls to f. * testsuite/libgomp.c/parloops-exit-first-loop-alt.c: Same. * gcc.dg/parloops-exit-first-loop-alt-pr66652.c: New test. * gcc.dg/parloops-exit-first-loop-alt-3.c (f): Rewrite using restrict pointers. * gcc.dg/parloops-exit-first-loop-alt.c: Same. 2015-06-29 Tom de Vries t...@codesourcery.com * tree-parloops.c (try_transform_to_exit_first_loop_alt): Simplify function structure. 2015-06-23 Tom de Vries t...@codesourcery.com * testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c (main): Use abort. * testsuite/libgomp.c/parloops-exit-first-loop-alt-4.c (main): Same. 2015-06-22 Tom de Vries t...@codesourcery.com * tree-parloops.c (transform_to_exit_first_loop_alt): Add update_stmt for cond_stmt. 2015-06-13 Tom de Vries t...@codesourcery.com * gcc.dg/parloops-exit-first-loop-alt-4.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt-4.c: New test. * testsuite/libgomp.c/parloops-exit-first-loop-alt-2.c: Add comment. * testsuite/libgomp.c/parloops-exit-first-loop-alt.c: Same. * testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c: Add comment. (N): Define. (main): Use N instead of hardcoded constants. * gcc.dg/parloops-exit-first-loop-alt-2.c: Add comment. (main): Remove superfluous attributes. * gcc.dg/parloops-exit-first-loop-alt-3.c: Same. * gcc.dg/parloops-exit-first-loop-alt.c: Same. Added: branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-4.c - copied, changed from r225165, branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-3.c branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-pr66652.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-4.c - copied, changed from r225165, branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-2.c branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt-3.c branches/gomp-4_0-branch/gcc/testsuite/gcc.dg/parloops-exit-first-loop-alt.c branches/gomp-4_0-branch/gcc/tree-parloops.c branches/gomp-4_0-branch/libgomp/ChangeLog.gomp branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-2.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt.c
[Bug tree-optimization/66642] transform_to_exit_first_loop_alt doesn't use result of low iteration count loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66642 --- Comment #5 from vries at gcc dot gnu.org --- Author: vries Date: Tue Jun 30 09:57:40 2015 New Revision: 225167 URL: https://gcc.gnu.org/viewcvs?rev=225167root=gccview=rev Log: Add empty loop exit block in transform_to_exit_first_loop_alt 2015-06-30 Tom de Vries t...@codesourcery.com PR tree-optimization/66642 * tree-parloops.c (transform_to_exit_first_loop_alt): Update function header comment. Rename split_edge variable to edge_at_split. Split exit edge to create new loop exit bb. Insert loop exit phis in new loop exit bb. * testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c (main): Test low iteration count case. * testsuite/libgomp.c/parloops-exit-first-loop-alt.c (init): New function, factor out of ... (main): ... here. Test low iteration count case. Modified: branches/gomp-4_0-branch/gcc/ChangeLog.gomp branches/gomp-4_0-branch/gcc/tree-parloops.c branches/gomp-4_0-branch/libgomp/ChangeLog.gomp branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt-3.c branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/parloops-exit-first-loop-alt.c
[Bug libgomp/65742] [5 Regression] Several libgomp.oacc-* failures after r221922.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65742 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|NEW |ASSIGNED Summary|[5/6 Regression] Several|[5 Regression] Several |libgomp.oacc-* failures |libgomp.oacc-* failures |after r221922. |after r221922. --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk - can you please fix the gcc 5 branch as well?
[Bug ipa/65797] [5/6 regression] IPA ICF causes function to be emitted with no debug line info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65797 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Component|tree-optimization |ipa Summary|[5 regression] IPA ICF |[5/6 regression] IPA ICF |causes function to be |causes function to be |emitted with no debug line |emitted with no debug line |info|info --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- The underlying issue wasn't fixed on trunk just the symptom in libgo.
[Bug middle-end/66432] libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66432 --- Comment #4 from vries at gcc dot gnu.org --- Testing tentative patch
[Bug rtl-optimization/66706] Redundant bitmask instruction on x (n 32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66706 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-30 Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool segher at gcc dot gnu.org --- For some reason when combining the zero_extend with the lshiftrt, combine writes it as the equivalent and-of-subreg. Which doesn't match any existing backend pattern. Confirmed; mine.
[Bug debug/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66653 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 30 15:40:38 2015 New Revision: 225193 URL: https://gcc.gnu.org/viewcvs?rev=225193root=gccview=rev Log: PR debug/66653 * decl2.c (is_late_template_attribute): True for tls_model. Added: trunk/gcc/testsuite/g++.dg/tls/tls_model1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552 --- Comment #3 from Martin Sebor msebor at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #2) I opened bug 66706.
[Bug debug/66691] [5/6 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Thanks for reporting this. I've started work on it.
[Bug rtl-optimization/66706] New: Redundant shift instruction on x (n 32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66706
Bug ID: 66706
Summary: Redundant shift instruction on x (n 32)
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org, msebor at gcc dot gnu.org,
rv at rasmusvillemoes dot dk, segher at gcc dot gnu.org,
unassigned at gcc dot gnu.org
Depends on: 66552
Target Milestone: ---
Target: x86, powerpc64
+++ This bug was initially created as a clone of Bug #66552 +++
Compiling the following function with -O2:
unsigned f(unsigned x, int n)
{
return x (n 32);
}
results in an unnecessary instruction to zero out the already clear high order
bits of register 3 after the shift instruction:
rldicl 4,4,0,59
srw 3,3,4
rldicl 3,3,0,32
blr
Clang emits an optimal sequence:
rlwinm 4, 4, 0, 27, 31
srw 3, 3, 4
blr
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552
[Bug 66552] Missed optimization when shift amount is result of signed modulus
[Bug debug/66653] [6 Regression] ice in gen_type_die_with_usage, at dwarf2out.c:20876
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66653 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 30 14:31:36 2015 New Revision: 225192 URL: https://gcc.gnu.org/viewcvs?rev=225192root=gccview=rev Log: PR debug/66653 * cp-tree.h (CP_DECL_THREAD_LOCAL_P): New. (DECL_GNU_TLS_P): Use DECL_LANG_SPECIFIC field. (SET_DECL_GNU_TLS_P): New. * call.c (make_temporary_var_for_ref_to_temp): Use CP_DECL_THREAD_LOCAL_P. (set_up_extended_ref_temp): Likewise. * decl.c (duplicate_decls, expand_static_init): Likewise. (redeclaration_error_message, grokvardecl): Likewise. (start_decl, register_dtor_fn, grokdeclarator): Likewise. * decl2.c (get_guard, var_needs_tls_wrapper): Likewise. (handle_tls_init): Likewise. * pt.c (tsubst_decl, tsubst_copy_and_build): Likewise. * semantics.c (finish_id_expression): Likewise. (handle_omp_array_sections_1, finish_omp_clauses): Likewise. (finish_omp_threadprivate): Likewise. * tree.c (decl_storage_duration): Likewise. * cp-gimplify.c (omp_var_to_track): Likewise. (cp_genericize_r): Check that it matches DECL_THREAD_LOCAL_P. * lex.c (retrofit_lang_decl): Return if DECL_LANG_SPECIFIC is already set. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/tls1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/lex.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c
[Bug fortran/66708] New: Possible (minor) improvement on formatted io with format too short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66708 Bug ID: 66708 Summary: Possible (minor) improvement on formatted io with format too short Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Formatted read or write of a variable (list) needs a format (fmt) string longer than 2 characters, because of parentheses ( ) and at least one character for an edit descriptor (e.g. a, g0, i8). At least if the fmt string is constant/unchangeable, an error message could be given at compile time. Otherwise a runtime error occurs. Here with write, same for read and print. $ cat z_write_fmt_too_short_2_item.f90 program p character(2), parameter :: fmt1 = '()' character(2) :: fmt2 = '()' integer :: n = 1 3 format () write (*, fmt1) n write (*, fmt2) n write (*, '()') n write (*, 3) n end $ gfortran -g -O0 -Wall -fcheck=all z_write_fmt_too_short_2_item.f90 $ a.out At line 6 of file z_write_fmt_too_short_2_item.f90 (unit = 6, file = 'stdout') Fortran runtime error: Insufficient data descriptors in format after reversion
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 Martin Sebor msebor at gcc dot gnu.org changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor msebor at gcc dot gnu.org --- The code doesn't look valid to me: Y is not a valid template argument for the template template parameter C. Of the compilers I tried GCC, EDG eccp, and IBM XLC++ all reject it (the latter two with a clear error message confirming the above). Clang is the only one that accepts it.
[Bug fortran/66708] Possible (minor) improvement on formatted io with format too short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66708
Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de
---
Formatted read or write with no variable list needs a format (fmt)
string longer than one character.
This is checked already -- partly -- but very good, indeed.
Please take a look at the message text.
$ cat z_write_fmt_too_short_1.f90
program p
character(1), parameter :: fmt1 = '('
character(1) :: fmt2 = '('
write (*, fmt1)
write (*, fmt2)
write (*, '(')
end
$ gfortran -g -O0 -Wall -fcheck=all z_write_fmt_too_short_1.f90
z_write_fmt_too_short_1.f90:4:14:
write (*, fmt1)
1
Error: Unexpected end of format string in format string at (1)
z_write_fmt_too_short_1.f90:6:14: Error: Unexpected end of format string in
format string at (1)
---
$ cat z_write_fmt_too_short_0.f90
program p
character(1), parameter :: fmt1 = '('
character(1) :: fmt2 = '('
write (*, fmt1(1:0))
write (*, fmt2(1:0))
write (*, '')
end
$ gfortran z_write_fmt_too_short_0.f90
z_write_fmt_too_short_0.f90:4:13:
write (*, fmt1(1:0))
1
Error: Missing leading left parenthesis in format string at (1)
z_write_fmt_too_short_0.f90:6:13:
write (*, '')
1
Error: Missing leading left parenthesis in format string at (1)
[Bug libstdc++/66699] Incorrect order of destruction for std::tuple elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66699 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Antony Polukhin from comment #3) std::pair destruction order is fully specified, so that order must be used by tuple too. No, the standard says no such thing.
[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 James Greenhalgh jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added CC||jgreenhalgh at gcc dot gnu.org --- Comment #13 from James Greenhalgh jgreenhalgh at gcc dot gnu.org --- Starting with my own set of silly questions while I try to narrow down what environments I need to set up... Your toolchain is arm-none-linux-gnueabi , but you build with -mfloat-abi=hard - do you have suitable hard-float libraries on the target? How was the toolchain configured (arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ -v)? What userspace is running on the target?
[Bug debug/66691] [5/6 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Tue Jun 30 17:40:55 2015 New Revision: 225200 URL: https://gcc.gnu.org/viewcvs?rev=225200root=gccview=rev Log: 2015-06-30 Vladimir Makarov vmaka...@redhat.com PR debug/66691 * lra-int.h (lra_substitute_pseudo): Add a parameter. (lra_substitute_pseudo_within_insn): Ditto. * lra.c (lra_substitute_pseudo): Add a parameter. Simplify subreg of constant. (lra_substitute_pseudo_within_insn): Add a parameter. Transfer it to lra_substitute_pseudo. * lra-lives.c (process_bb_lives): Add an argument to lra_substitute_pseudo_within_insn call. * lra-constraints.c (inherit_reload_reg, split_reg): Add an argument to lra_substitute_pseudo and lra_substitute_pseudo_within_insn calls. (remove_inheritance_pseudos, undo_optional_reloads): Ditto. 2015-06-30 Vladimir Makarov vmaka...@redhat.com PR debug/66691 * gcc.target/i386/pr66691.c: New. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra-int.h trunk/gcc/lra-lives.c trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66710] New: Unhelpful error message with unbalanced parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66710 Bug ID: 66710 Summary: Unhelpful error message with unbalanced parenthesis Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: casey.webster at gmail dot com Target Milestone: --- A very simple test case: real, dimension(1,1) :: A b = A(:,iter)) end whose error is unbalanced parenthesis on line two, fails compilation as it should, but for a very unhelpful (and wrong) error: error-msg.f90:2:10: b = A(:,iter)) 1 Error: Invalid character in name at (1) For comparison, ifort emits the error error #5276: Unbalanced parentheses for the same testcase.
[Bug fortran/66709] New: ICE on formatted io with parameter array specifier fmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66709
Bug ID: 66709
Summary: ICE on formatted io with parameter array specifier fmt
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: gerhard.steinmetz.fort...@t-online.de
Target Milestone: ---
Specifying a character array for fmt is legal fortran.
If declared as parameter, compilation fails :
$ cat z_wr_fmt_ice_1.f90
program p
character(4), parameter :: fmt(1) = '(i8)'
integer :: n
read (*, fmt=fmt) n
write (*, fmt=fmt) n
end
$ cat z_wr_fmt_ice_2.f90
program p
character(*), parameter :: fmt(1) = '(i8)'
integer :: n
read (*, fmt=fmt) n
write (*, fmt=fmt) n
end
$ cat z_wr_fmt_ice_5.f90
program p
character(1), parameter :: fmt(4) = ['(', 'i', '8', ')']
integer :: n
read (*, fmt=fmt) n
write (*, fmt=fmt) n
end
yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit) :
internal compiler error: in gfc_conv_array_constructor_expr, at
fortran/trans-expr.c:6326
[Bug fortran/66707] New: Endless compilation on wrong usage of common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66707 Bug ID: 66707 Summary: Endless compilation on wrong usage of common Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- After printing some correct and helpful error messages, compilation of the following snippets (wrong code) will not end. Tested with gfortran 5.1.1, 4.9.0, 4.8.3 (on SUSE Linux 13.2, 64 bit). $ cat zlctc_1.f90 program p c = 1 common // c common // c end $ cat zlctc_2.f90 program p integer, pointer :: a common a, a common a end $ cat zlctc_3.f90 program p integer, pointer :: a common a = null() common a = null() end $ time gfortran zlctc_1.f90 zlctc_1.f90:3.14: common // c 1 Error: Unexpected COMMON statement at (1) zlctc_1.f90:4.14: common // c 1 Error: Unexpected COMMON statement at (1) # ^C after a few minutes
[Bug c++/66701] __cxxabiv1::__cxa_pure_virtual - can it take an argument of the pointer to the function that was called, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66701 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The function signature is defined by the ABI so we can't change it. http://mentorembedded.github.io/cxx-abi/abi.html#pure-virtual
[Bug libstdc++/66699] Incorrect order of destruction for std::tuple elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66699 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- And that's not even what similar means anyway.
[Bug fortran/66575] Endless compilation on missing end interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66575 --- Comment #3 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de --- Playing around, I've found other cases (wrong code with procedure) causing endless compilation on my environment, e.g. $ cat zlctp_1.f90 program p procedure(g) :: g procedure(g) :: g end $ cat zlctp_2.f90 program p procedure(g) :: g procedure(g) !! anything end $ time gfortran -c zlctp_2.f90 # with 5.1.1, 4.9.0, 4.8.3 # ^C after a few minutes real3m46.187s user0m0.000s sys 0m0.002s
[Bug libstdc++/66699] Incorrect order of destruction for std::tuple elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66699 --- Comment #4 from Martin Sebor msebor at gcc dot gnu.org --- Being described as similar doesn't imply they are identical in every detail. std::pair and std::tuple are distinct classes with different requirements on each. If you believe the are required to behave identically in this respect (i.e., have their subobjects defined in the same order) you need to point to the specific wording that guarantees it.
[Bug fortran/66709] ICE on formatted io with parameter array specifier fmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66709
--- Comment #1 from Gerhard Steinmetz gerhard.steinmetz.fort...@t-online.de
---
Whereas versions without parameter compile and run fine :
$ cat z_wr_fmt_ice_4.f90
program p
character(4) :: fmt(1) = '(i8)'
integer :: n
read (*, fmt=fmt) n
write (*, fmt=fmt) n
end
$ cat z_wr_fmt_ice_6.f90
program p
character(1) :: fmt(4) = ['(', 'i', '8', ')']
integer :: n
read (*, fmt=fmt) n
write (*, fmt=fmt) n
end
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #2 from Patrick Palka ppalka at gcc dot gnu.org --- (In reply to Martin Sebor from comment #1) The code doesn't look valid to me: Y is not a valid template argument for the template template parameter C. But once struct X gets instantiated like in the very last line, doesn't it become a valid template argument? There, B is set to int, thus the template parameter C gets the type template int class which is exactly the type of the template Y.
[Bug rtl-optimization/66665] Increment instruction is not propagated into address operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-06-30 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It is caused by the combination of -mregparm=3 -mtune=i686. -mregparm=3 -mtune=generic -O2 gives f: .cfi_startproc movsbl a+1(%eax), %edx movsbl b+1(%eax), %eax addl%edx, %eax ret .cfi_endproc
[Bug debug/66691] [5/6 Regression] ICE on valid code at -O3 with -g enabled in simplify_subreg, at simplify-rtx.c:5744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66691 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org --- I'll commit the same patch into gcc-5 branch on next week after some testing the patch on trunk.
[Bug c++/60365] multiple noreturn attribute specifiers in a single declaration doesn't result in a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60365 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-30 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug c/66711] GCC does not correctly restore diagnostic state after pragma GCC diagnostic pop with -Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66711 --- Comment #1 from Steffen Müthing steffen.muething at iwr dot uni-heidelberg.de --- I just noticed the wrong filename (error.cc) and driver (cc1plus) in the first two outputs: I compiled those with g++ instead of gcc, but the same problem is present in the C frontend.
[Bug jit/66628] jit: Provide a way to add arbitrary options to the toplev command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66628 --- Comment #1 from David Malcolm dmalcolm at gcc dot gnu.org --- Author: dmalcolm Date: Tue Jun 30 19:27:19 2015 New Revision: 225205 URL: https://gcc.gnu.org/viewcvs?rev=225205root=gccview=rev Log: PR jit/66628: add gcc_jit_context_add_command_line_option gcc/jit/ChangeLog: PR jit/66628 * docs/cp/topics/contexts.rst (Additional command-line options): New section. * docs/topics/compatibility.rst: New file. * docs/topics/contexts.rst (Additional command-line options): New section. * docs/topics/index.rst: Add compatibility.rst. * docs/_build/texinfo/libgccjit.texi: Regenerate. * jit-playback.c (make_fake_args): Add call to append_command_line_options. * jit-recording.c: Within namespace gcc::jit... (recording::context::~context): Free the optnames within m_command_line_options. (recording::context::set_bool_option): Likewise. (recording::context::add_command_line_option): New method. (recording::context::append_command_line_options): New method. (recording::context::dump_reproducer_to_file): Add command-line options. * jit-recording.h: Within namespace gcc::jit... (recording::context::add_command_line_option): New method. (recording::context::append_command_line_options): New method. (recording::context::m_command_line_options): New field. * libgccjit++.h (gccjit::context::add_command_line_option): New method. * libgccjit.c (gcc_jit_context_add_command_line_option): New API entrypoint. * libgccjit.h (gcc_jit_context_add_command_line_option): New API entrypoint. (LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option): New macro. * libgccjit.map: Put existing symbols within LIBGCCJIT_ABI_0; add LIBGCCJIT_ABI_1 and gcc_jit_context_add_command_line_option. gcc/testsuite/ChangeLog: PR jit/66628 * jit.dg/all-non-failing-tests.h: Add note about test-extra-options.c. * jit.dg/test-extra-options.c: New testcase. Added: trunk/gcc/jit/docs/topics/compatibility.rst trunk/gcc/testsuite/jit.dg/test-extra-options.c Modified: trunk/gcc/jit/ChangeLog trunk/gcc/jit/docs/_build/texinfo/libgccjit.texi trunk/gcc/jit/docs/cp/topics/contexts.rst trunk/gcc/jit/docs/topics/contexts.rst trunk/gcc/jit/docs/topics/index.rst trunk/gcc/jit/jit-playback.c trunk/gcc/jit/jit-recording.c trunk/gcc/jit/jit-recording.h trunk/gcc/jit/libgccjit++.h trunk/gcc/jit/libgccjit.c trunk/gcc/jit/libgccjit.h trunk/gcc/jit/libgccjit.map trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/jit.dg/all-non-failing-tests.h
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #3 from Patrick Palka ppalka at gcc dot gnu.org --- (In reply to Patrick Palka from comment #2) (In reply to Martin Sebor from comment #1) The code doesn't look valid to me: Y is not a valid template argument for the template template parameter C. But once struct X gets instantiated like in the very last line, doesn't it become a valid template argument? There, B is set to int, thus the template parameter C gets the type template int class which is exactly the type of the template Y. Err, I meant the parameter Z gets the type template int class which is exactly the type of the template Y. So it seems that early-rejecting this template definition is too pessimistic because there exist template arguments that make the instantiated code valid.
[Bug tree-optimization/66713] New: atomic compare_excahnge_strong create spurious store for x86-64 at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66713 Bug ID: 66713 Summary: atomic compare_excahnge_strong create spurious store for x86-64 at -O3 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tkoeppe at google dot com Target Milestone: --- The code here: https://goo.gl/CiV4pl compares a hand-written CAS with the C++11 atomic one. On Clang, the code comes out identical. On GCC 4.9.2 and later there is an extra store (movq %rdi, -8(%rsp)). Should that not be there?
[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com --- ix86_function_regparm has /* We don't want to use regparm(3) for nested functions as these use a static chain pointer in the third argument. */ if (local_regparm == 3 DECL_STATIC_CHAIN (target-decl)) local_regparm = 2; /* Save a register for the split stack. */ if (local_regparm == 3 flag_split_stack) local_regparm = 2; /* Each fixed register usage increases register pressure, so less registers should be used for argument passing. This functionality can be overriden by an explicit regparm value. */ for (regno = AX_REG; regno = DI_REG; regno++) if (fixed_regs[regno]) globals++; local_regparm = globals local_regparm ? local_regparm - globals : 0; if (local_regparm regparm) ^^^ Shouldn't it be ? regparm = local_regparm; }
[Bug middle-end/66685] [6 Regression] conftest.c:16:1: internal compiler error: in as_a, at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66685 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-06-30 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Created attachment 35883 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35883action=edit Possible fix Sorry, I missed that this was after r225000. Does the attached patch fix it?
[Bug jit/66546] No way to disable check for unreachable blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66546 --- Comment #3 from David Malcolm dmalcolm at gcc dot gnu.org --- Author: dmalcolm Date: Tue Jun 30 19:38:12 2015 New Revision: 225206 URL: https://gcc.gnu.org/viewcvs?rev=225206root=gccview=rev Log: PR jit/66546: Add gcc_jit_context_set_bool_allow_unreachable_blocks gcc/jit/ChangeLog: PR jit/66546 * docs/cp/topics/contexts.rst (gccjit::context::set_bool_allow_unreachable_blocks): New. * docs/topics/compatibility.rst (LIBGCCJIT_ABI_2): New. * docs/topics/contexts.rst (Options): Add notes discussing the transition from enums to entrypoints for new options. (gcc_jit_context_set_bool_allow_unreachable_blocks): New. * docs/_build/texinfo/libgccjit.texi: Regenerate. * jit-common.h (gcc::jit::inner_bool_option): New enum. * jit-recording.c: Within namespace gcc::jit... (recording::context::context): Handle m_inner_bool_options. (recording::context::set_inner_bool_option): New. (inner_bool_option_reproducer_strings): New. (recording::context::log_all_options): Log the inner bool options. (recording::context::log_inner_bool_option): New. (recording::context::dump_reproducer_to_file): Write initializers for inner bool options. (recording::function::validate): Don't check for block reachability if INNER_BOOL_OPTION_ALLOW_UNREACHABLE_BLOCKS is set. * jit-recording.h: Within namespace gcc::jit... (recording::context::set_inner_bool_option): New. (recording::context::get_inner_bool_option): New. (recording::context::log_inner_bool_option): New. (recording::context::m_inner_bool_options): New. * libgccjit++.h (gccjit::context::set_bool_allow_unreachable_blocks): New. * libgccjit.c (gcc_jit_context_set_bool_allow_unreachable_blocks): New. * libgccjit.h: Add note about options present in the initial release of libgccjit. (gcc_jit_context_set_bool_allow_unreachable_blocks): New API entrypoint. (LIBGCCJIT_HAVE_gcc_jit_context_set_bool_allow_unreachable_blocks): New macro. * libgccjit.map (LIBGCCJIT_ABI_2): New, containing... (gcc_jit_context_set_bool_allow_unreachable_blocks): ...this new entrypoint. gcc/testsuite/ChangeLog: PR jit/66546 * jit.dg/all-non-failing-tests.h: Add note about test-validly-unreachable-block.c. * jit.dg/test-validly-unreachable-block.c: New file. Added: trunk/gcc/testsuite/jit.dg/test-validly-unreachable-block.c Modified: trunk/gcc/jit/ChangeLog trunk/gcc/jit/docs/_build/texinfo/libgccjit.texi trunk/gcc/jit/docs/cp/topics/contexts.rst trunk/gcc/jit/docs/topics/compatibility.rst trunk/gcc/jit/docs/topics/contexts.rst trunk/gcc/jit/jit-common.h trunk/gcc/jit/jit-recording.c trunk/gcc/jit/jit-recording.h trunk/gcc/jit/libgccjit++.h trunk/gcc/jit/libgccjit.c trunk/gcc/jit/libgccjit.h trunk/gcc/jit/libgccjit.map trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/jit.dg/all-non-failing-tests.h
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686
--- Comment #4 from Martin Sebor msebor at gcc dot gnu.org ---
Y takes a non-type template argument which isn't provided and can't be deduced
in the instantiation (i.e., what would the value of N be in YN?)
Modifying the test case a bit to see the type Clang gives a.a shows that it
winds up instantiating an object of type AY even though no such type exists,
indicating it's a Clang bug.
$ cat t.cpp /build/llvm-3.6.0/bin/clang++ -Wall -Wextra -Wpedantic
t.cpptemplate template int class struct A { };
template int struct Y { };
template class, class B, template template B class class C
struct X { CY a; };
Xint, int, A a;
template class T void foo (T);
int main () { foo (a.a); }
/tmp/t-310f66.o: In function `main':
t.cpp:(.text+0x9): undefined reference to `void fooAY (AY)'
clang-3.6: error: linker command failed with exit code 1 (use -v to see
invocation)
[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 35882 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35882action=edit A patch
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686
--- Comment #5 from Patrick Palka ppalka at gcc dot gnu.org ---
(In reply to Martin Sebor from comment #4)
Y takes a non-type template argument which isn't provided and can't be
deduced in the instantiation (i.e., what would the value of N be in YN?)
Can't you say that for all templates passed as arguments to template template
parameters?
Modifying the test case a bit to see the type Clang gives a.a shows that it
winds up instantiating an object of type AY even though no such type
exists, indicating it's a Clang bug.
I'm not sure I understand when you say that the type AY does not exist. I
can declare the variable AY zzz; just fine, and I can declare a function
that takes an AY as an argument, for example. AY seems like a standard
template.
$ cat t.cpp /build/llvm-3.6.0/bin/clang++ -Wall -Wextra -Wpedantic
t.cpptemplate template int class struct A { };
template int struct Y { };
template class, class B, template template B class class C
struct X { CY a; };
Xint, int, A a;
template class T void foo (T);
int main () { foo (a.a); }
/tmp/t-310f66.o: In function `main':
t.cpp:(.text+0x9): undefined reference to `void fooAY (AY)'
clang-3.6: error: linker command failed with exit code 1 (use -v to see
invocation)
Sorry for my misunderstanding, I can't quite see the problem here.
[Bug libstdc++/66624] libstdc++ iostream uninitialized data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66624 Richard Kettlewell richard+gcc at sfere dot greenend.org.uk changed: What|Removed |Added CC||richard+gcc at sfere dot greenend. ||org.uk --- Comment #3 from Richard Kettlewell richard+gcc at sfere dot greenend.org.uk --- (I'm 'richard@deodand'.) So this is a bug in Clang (or at least in its -fsanitize implementation) then?
[Bug c/66711] New: GCC does not correctly restore diagnostic state after pragma GCC diagnostic pop with -Werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66711 Bug ID: 66711 Summary: GCC does not correctly restore diagnostic state after pragma GCC diagnostic pop with -Werror Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: steffen.muething at iwr dot uni-heidelberg.de Target Milestone: --- Created attachment 35880 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35880action=edit MWE, compile with gcc -Wextra -Werror wrong-diagnostic-pop.c GCC 5.1.0 fails to correctly restore the diagnostics state after a #pragma GCC diagnostic pop if the program was compiled with -Werror: Instead of emitting an error, the compiler insteads issues a warning after the pragma. I've attached a simple example file. When compiled with -Wextra -Werror, I'd expect the output: error.cc: In function 'int main()': error.cc:9:10: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] x += x y ? 1 : 0; ^ error.cc:18:10: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] x += x y ? 1 : 0; ^ cc1plus: all warnings being treated as errors But I get the following: error.cc: In function 'int main()': error.cc:9:10: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] x += x y ? 1 : 0; ^ error.cc:18:10: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] x += x y ? 1 : 0; ^ cc1plus: all warnings being treated as errors The second diagnostic was turned into a warning. All older versions of GCC that I have available and that support diagnostic push/pop (4.6.4, 4.7.4, 4.8.4, 4.9.2) handle this correctly and issue an error in both cases. Example output from GCC 4.9.2: wrong-diagnostic-pop.c: In function 'main': wrong-diagnostic-pop.c:9:10: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] x += x y ? 1 : 0; ^ wrong-diagnostic-pop.c:18:10: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] x += x y ? 1 : 0; ^ cc1: all warnings being treated as errors The problem is also present in the C++ frontend.
[Bug c++/66712] New: [concepts] variadic concepts cause havoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66712
Bug ID: 66712
Summary: [concepts] variadic concepts cause havoc
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
template class T, class...Args
concept bool _Constructible_ =
requires (Args...args)
{
T{ ((Args)(args))... };
};
template class T, class...Args
constexpr bool _constructible_() { return false; }
_Constructible_{T, ...Args...}
constexpr bool _constructible_() { return true; }
struct S
{
S(int, char const *);
};
int main()
{
static_assert(_constructible_S, int, char const *(), );
}
Result:
temp.cpp: In function ‘int main()’:
temp.cpp:22:55: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search.c:224
static_assert(_constructible_S, int, char const *(), );
^
temp.cpp:22:55: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The trouble with variadic concepts is a blocker for STL2.
[Bug rtl-optimization/66665] Increment instruction is not propagated into address operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |6.0
[Bug rtl-optimization/66665] Increment instruction is not propagated into address operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 35881 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35881action=edit A patch This patch fixes -mtune=i686 and -mtune=i586.
[Bug other/65732] stack overflow while demangling _ZNK7VectorTIfEmlIfvEES_IDTmlcvf_EcvT__EEERKS2_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65732 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- 492e19d098f4 in binutils is r205292 in gcc.
[Bug c++/66666] ARM wrong copy constructor address on multiple inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #11 from Antonio Poggiali antonio.poggiali at datalogic dot com --- (In reply to Mikael Pettersson from comment #10) (In reply to Antonio Poggiali from comment #9) Sorry, this code: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cgraphunit. c?r1=221077r2=221076pathrev=221077 Yes, but I'm not convinced it's the real fix. Unfortunately I can't use gcc 5 (I'm trying but it's not so easy) so, up to now, this patch is the only way to get my system working. Do you think this bug will be fixed in a new release (e.g. 4.9.4)? Thank you!
[Bug middle-end/66702] New: #pragma omp declare simd uniform and linear issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66702
Bug ID: 66702
Summary: #pragma omp declare simd uniform and linear issues
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
void
bar (int a, int b, int *c, int d)
{
volatile int x;
int *volatile y;
x = a; a = x;
x = b; b = x;
y = c; c = y;
x = d; d = x;
}
void (*volatile barp) (int , int , int *, int ) = bar;
#pragma omp declare simd uniform(b, c) linear(d:2) aligned(c:32) notinbranch
int
foo (int a, int b, int *c, int d)
{
a++;
b++;
c += 8;
d += 2;
barp (a, b, c, d);
return a + b + *c + d;
}
volatile int e = 5;
int c[64] __attribute__((aligned (32)));
int
main ()
{
int d = 7, r = 0;
int b = e;
for (int i = 0; i 64; i++)
c[i] = i;
#pragma omp simd reduction(+:r) linear(d:2)
for (int i = 0; i 64; i++)
{
r += foo (i, b, c, d);
d += 2;
}
if (r != 7584)
__builtin_abort ();
}
is miscompiled with -O2 -fopenmp, because uniform and linear clauses were
properly handled only for non-addressable variables of gimple type.
For addressable vars (both linear and uniform) or for non-gimple types or C++
args passed by invisible reference (uniform only), if the arguments are
modified in the function, we need to make a copy of the initial var and restore
it for each VL.
[Bug libstdc++/62258] [4.9/5 Regression] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Known to work|4.8.1 |4.8.0, 4.8.2, 6.0 Summary|[4.9/5/6 Regression]|[4.9/5 Regression] |uncaught_exception() equals |uncaught_exception() equals |to `true' after |to `true' after |rethrow_exception() |rethrow_exception() Known to fail|4.8.2, 5.0 |4.8.3, 4.8.5, 5.1.0 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- I can confirm it works with 4.8.0 to 4.8.2 but fails since 4.8.3 (just verified using -static-libstdc++ to not fool myself with the installed runtime).
[Bug libstdc++/62258] [4.9/5 Regression] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug target/66137] [4.9/5/6 Regression] ICE with -ffixed-ebp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66137 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug testsuite/66667] FAIL: g++.dg/diagnostic/inhibit-warn-2.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Fixed for GCC 5.2 (https://gcc.gnu.org/ml/gcc-regression/2015-06/msg00712.html).
[Bug c++/66121] [5 Regression] internal compiler error: in strip_typedefs, at cp/tree.c:1369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66121 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/66263] [4.9/5/6 Regression] Performance regression from gcc-4.8 and up (trivial sudoku program)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66263
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |RESOLVED
Known to work||4.7.4
Resolution|--- |DUPLICATE
Known to fail||4.8.3, 5.1.0
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
Confirmed, for me:
4.7.4: 0.77s
4.8.3: 1.5s
5.1: 1.57s
with -O3, time with -O2 didn't regress. Even with -fno-inline it regresses:
4.7.4 -O3 -fno-inline: 1.7s
5.1 -O3 -fno-inline: 2.3s
Ok, 4.7 unrolls the
for (digit = 1; digit = N; ++digit) {
if (can_put_digit(row, col, box, digit)) {
put_digit(row, col, box, digit);
solve(square+1);
pop_digit(row, col, box, digit);
}
}
loop, so this looks like a duplicate of PR59967. It also re-orders
basic-blocks in a way that if can_put_digit returns false (which should
be likely in the end) then it just falls thru to the next can_put_digit call.
With inlining the non-pure call is the recursion to solve ().
*** This bug has been marked as a duplicate of bug 59967 ***
[Bug tree-optimization/59967] [4.9/5/6 Regression] Performance regression from 4.7.x to 4.8.x (loop not unrolled)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59967 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||bdeyal at gmail dot com --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 66263 has been marked as a duplicate of this bug. ***
[Bug testsuite/66621] [4.9/5 Regression] Mistakenly unsupported tests in g++.dg/torture/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66621 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|[4.9/5/6 Regression]|[4.9/5 Regression] |Mistakenly unsupported |Mistakenly unsupported |tests in g++.dg/torture/|tests in g++.dg/torture/ --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66626 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug target/66648] [4.9/5/6 regression] incorrect memcpy expansion with unrolled_loop strategy at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66648 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/60364] [[noreturn]] specified for second declaration but not first doesn't result in a diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60364 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Nope.
[Bug tree-optimization/66522] handle casts in nr of iterations in try_transform_to_exit_first_loop_alt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66522 --- Comment #3 from vries at gcc dot gnu.org --- (In reply to vries from comment #2) https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00965.html Unproposing patch, as discussed here: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02086.html New patch: https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02085.html
[Bug c++/66686] Instantiation of dependent template template parameter with non-dependent template rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66686 --- Comment #6 from Martin Sebor msebor at gcc dot gnu.org --- The misunderstanding was mine -- I had forgotten that a template template can be instantiated on a template without providing or deducing the arguments for the latter. Please disregard my comment #4.
[Bug libgomp/66715] libgomp.oacc-c/../libgomp.oacc-c-c++-common/data-{2,3}.c exec fails -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66715 vries at gcc dot gnu.org changed: What|Removed |Added Version|unknown |6.0 --- Comment #1 from vries at gcc dot gnu.org --- This failure also reproduces on trunk
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #40 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #39) Can we close this PR as fixed? I've got Testsuite summary for MPFR 3.1.3 # TOTAL: 160 # PASS: 159 # SKIP: 1 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 with my 4.9 native compiler built with 4.9 cross compiler for svn gcc-4_9-branch. I hope that miscompilation for mpfr is gone for bootstrapped 4.9 compiler and it fixes the original gcc issue too. Matthias, Adrian, what about the original error?
[Bug debug/66714] New: gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 Bug ID: 66714 Summary: gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- With gomp-4_0-branch, when running target-libgomp testsuite with --target_board=unix/-O2/-g, we have: c.exp: ... FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (internal compiler error) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors) ... c++.exp: ... FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error) FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors) FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (internal compiler error) FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/atomic_capture-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors) ... In more detail: ... src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c: In function ‘main._omp_fn.44’: src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c:817:9: internal compiler error: Segmentation fault 0xebeb50 crash_signal src/gcc/toplev.c:380 0x92e939 loc_list_from_tree src/gcc/dwarf2out.c:1 0x92ef5e loc_list_from_tree src/gcc/dwarf2out.c:14571 0x92f3e2 loc_list_from_tree src/gcc/dwarf2out.c:14645 0x92ef5e loc_list_from_tree src/gcc/dwarf2out.c:14571 0x93478c add_location_or_const_value_attribute src/gcc/dwarf2out.c:16088 0x940528 gen_variable_die src/gcc/dwarf2out.c:19277 0x946189 gen_decl_die src/gcc/dwarf2out.c:21028 0x94481d process_scope_var src/gcc/dwarf2out.c:20543 0x944896 decls_for_scope src/gcc/dwarf2out.c:20568 0x93c0c0 gen_subprogram_die src/gcc/dwarf2out.c:18869 0x945e09 gen_decl_die src/gcc/dwarf2out.c:20961 0x94708c dwarf2out_decl src/gcc/dwarf2out.c:21394 0x9470ae dwarf2out_function_decl src/gcc/dwarf2out.c:21402 0x9ecc5b rest_of_handle_final src/gcc/final.c:4525 0x9ecfce execute src/gcc/final.c:4567 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. ...
[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 --- Comment #1 from vries at gcc dot gnu.org --- For c.exp, at -Ofast/-g, this failure looks similar: ... FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c -DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors) ... In more detail: ... src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c: In function ‘test_reductions_minmax._omp_fn.6’: src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-1.c:96:1: internal compiler error: Segmentation fault 0xebeb50 crash_signal src/gcc/toplev.c:380 0x92e939 loc_list_from_tree src/gcc/dwarf2out.c:1 0x92ef5e loc_list_from_tree src/gcc/dwarf2out.c:14571 0x92f3e2 loc_list_from_tree src/gcc/dwarf2out.c:14645 0x92ef5e loc_list_from_tree src/gcc/dwarf2out.c:14571 0x93478c add_location_or_const_value_attribute src/gcc/dwarf2out.c:16088 0x940528 gen_variable_die src/gcc/dwarf2out.c:19277 0x946189 gen_decl_die src/gcc/dwarf2out.c:21028 0x94481d process_scope_var src/gcc/dwarf2out.c:20543 0x944896 decls_for_scope src/gcc/dwarf2out.c:20568 0x93c0c0 gen_subprogram_die src/gcc/dwarf2out.c:18869 0x945e09 gen_decl_die src/gcc/dwarf2out.c:20961 0x94708c dwarf2out_decl src/gcc/dwarf2out.c:21394 0x9470ae dwarf2out_function_decl src/gcc/dwarf2out.c:21402 0x9ecc5b rest_of_handle_final src/gcc/final.c:4525 0x9ecfce execute src/gcc/final.c:4567 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. ...
[Bug debug/66716] New: gomp4: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c -g ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66716 Bug ID: 66716 Summary: gomp4: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-lo op.c -g ICE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- With gomp-4_0-branch, when running target-libgomp testsuite with --target_board=unix/-O2/-g, we have: c.exp: ... FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (internal compiler error) FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors) ... in more detail ... src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c: In function ‘main’: src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c:41:1: error: definition in block 10 does not dominate use in block 19 for SSA_NAME: ii_69 in statement: # DEBUG ii = ii_69 src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/kernels-loop.c:41:1: internal compiler error: verify_ssa failed 0x1123966 verify_ssa(bool, bool) src/gcc/tree-ssa.c:1068 0xd1a9d8 execute_function_todo src/gcc/passes.c:1953 0xd19abf do_per_function src/gcc/passes.c:1638 0xd1ab76 execute_todo src/gcc/passes.c:2003 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 ...
