[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- But that is not in a header other packages use, it is in the source, and we aren't including stdbool.h. So this really looks like an eCos bug.
[Bug libstdc++/65631] seed_seq should not be copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- done
[Bug libstdc++/65631] seed_seq should not be copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65631 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Apr 28 12:35:30 2015 New Revision: 222524 URL: https://gcc.gnu.org/viewcvs?rev=222524root=gccview=rev Log: PR libstdc++/65631 * include/bits/random.h (seed_seq) Define copy constructor and copy assignment as deleted. * testsuite/26_numerics/random/seed_seq/cons/65631.cc: New. Added: trunk/libstdc++-v3/testsuite/26_numerics/random/seed_seq/cons/65631.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.h
[Bug tree-optimization/65917] New: [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917 Bug ID: 65917 Summary: [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: m68k-*-* $ gcc/xgcc -B gcc/ -O1 -fdump-tree-dom1 -S ../gcc/testsuite/gcc.dg/tree-ssa/20030922-2.c grep -c if 20030922-2.c.* 3 83617aa2bed0a6ac21010ba3b960d087bcb66f9b is the first bad commit commit 83617aa2bed0a6ac21010ba3b960d087bcb66f9b Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Apr 27 12:46:58 2015 + 2015-04-27 Richard Biener rguent...@suse.de * tree-ssa-dom.c (record_equivalences_from_phis): Valueize PHI arg. (record_equivalences_from_stmt): Valueize rhs. (record_equality): Canonicalize x and y order via tree_swap_operands_p. Do not swap operands for same loop depth. * gcc.target/i386/pr65217.c: XFAIL.
[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902 --- Comment #3 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Richard Earnshaw from comment #2) The standard headers should only be defining bool if stdbool.h has been included. So this looks more like a build environment error than a bug in GCC. yes. that is not too smart to define bool in the wrong header... but somehow we are also defining that in the wrong place?
[Bug c++/65734] Yet another case of lost alignment by stor_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65734 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Apr 28 14:43:48 2015 New Revision: 222529 URL: https://gcc.gnu.org/viewcvs?rev=222529root=gccview=rev Log: PR c++/65734 gcc/ * stor-layout.c (layout_type): Layout the TYPE_MAIN_VARIANT. (finalize_type_size): Respect TYPE_USER_ALIGN. (layout_type) [ARRAY_TYPE]: Likewise. gcc/cp/ * class.c (fixup_attribute_variants): Respect TYPE_USER_ALIGN. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alignas1.C trunk/gcc/testsuite/g++.dg/cpp0x/alignas2.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/stor-layout.c
[Bug c++/50800] Internal compiler error in finish_member_declarations, possibly related to may_alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Apr 28 14:43:54 2015 New Revision: 222530 URL: https://gcc.gnu.org/viewcvs?rev=222530root=gccview=rev Log: PR c++/50800 * tree.c (strip_typedefs): Add remove_attributes parm. (strip_typedefs_expr): Likewise. (apply_identity_attributes): New subroutine of strip_typedefs. * pt.c (canonicalize_type_argument): Let strip_typedefs handle attrs. (convert_nontype_argument, unify): Likewise. * cp-tree.h: Adjust. Added: trunk/gcc/testsuite/g++.dg/ext/attrib50.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/g++.dg/abi/mangle40.C trunk/gcc/testsuite/g++.dg/ext/alias-mangle.C
[Bug c++/65656] __builtin_constant_p should always be constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Apr 28 14:43:59 2015 New Revision: 222531 URL: https://gcc.gnu.org/viewcvs?rev=222531root=gccview=rev Log: PR c++/65656 * constexpr.c (cxx_eval_builtin_function_call): Fix __builtin_constant_p. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-builtin3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug tree-optimization/65918] Optimized code ( -O0) on 2-dim array iteration incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65918 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- while ((value limits[type][retval]) (retval 3)) well, the index gets out of bound. Check (retval 3) first.
[Bug target/65914] [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #15 from prathamesh3492 at gcc dot gnu.org --- Hi, I am not entirely sure, the issue seems to be in lto-wrapper. In lto-wrapper.c:run_gcc(): fdecoded_options, which are compiler options contains -mfpu=neon decoded_options, which are linker options contains -mfpu=vfpv3-d16. decoded_options are populated by lto-wrapper.c:get_options_from_collect_gcc_options() from environment variable COLLECT_GCC_OPTIONS. fdecoded_options are appended after decoded_options in run_gcc(): append_linker_options (argv_obstack, decoded_options, decoded_options_count); append_compiler_options (argv_obstack, fdecoded_options, fdecoded_options_count); which is why -mfpu=vfpv3-d16 overrides -mfpu=neon. Reversing the order of above function calls works fine for me for the above test-case. However I am not sure if this is the right approach, It now passes -mfpu=vfpv3-d16 and then it's overriden by -mfpu=neon since we reversed the order. Ideally we don't want -mfpu=vfpv3-d16 to appear ? I am not understanding why vfpv3-d16 appears in collect_gcc_options in run_gcc(). While writing COLLECT_GCC_OPTIONS in lto-opts.c:append_to_collect_gcc_options(), -mfpu=vfpv3-d16 is not present, Only -mfpu=neon is present, which is correct since it was passed as a command line option. I am not sure what modifies COLLECT_GCC_OPTIONS before it is read by run_gcc() in lto-wrapper. Thank you, Prathamesh
[Bug tree-optimization/65918] Optimized code ( -O0) on 2-dim array iteration incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65918 J. W. Mitchell habanero_pizza at yahoo dot com changed: What|Removed |Added CC||habanero_pizza at yahoo dot com --- Comment #1 from J. W. Mitchell habanero_pizza at yahoo dot com --- Created attachment 35414 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35414action=edit Preprocessed test case.
[Bug target/65914] [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 35415 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35415action=edit Somewhat reduced testcase
[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-04-28 CC||law at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Fixed by Jeffs later patch?
[Bug tree-optimization/65918] New: Optimized code ( -O0) on 2-dim array iteration incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65918
Bug ID: 65918
Summary: Optimized code ( -O0) on 2-dim array iteration
incorrect
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: habanero_pizza at yahoo dot com
Target Milestone: ---
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Created attachment 35413
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35413action=edit
Test case source: execution fails if OKAY is not defined...
When the following function is compiled with gcc 4.8.3, 4.9.2, or 5.1.0, it
only executes properly when no optimization is specified (-O0):
int f(int value, int type)
{
static const int limits[2][3] = {
{ 400, 480, 512 },
{ 460, 492, 500 }
};
int retval = 0;
while ((value limits[type][retval]) (retval 3)) {
retval++;
}
return retval;
}
The problem is in the case where retval should be 3; for example, if value is
550 and type is 0, the retval should be 3, but the function will return 2. For
cases where the function is supposed to return 0, 1, or 2, it does work
correctly.
However, if gcc 4.6.4 or gcc 4.7.2 is used, it works correctly with and without
optimization.
If the loop is changed to use an array of a single dimension, the problem is
also eliminated (4.8, 4.9, 5.1):
const int *limit = limits[type];
while ((value limit[retval]) (retval 3)) {
retval++;
}
I have also confirmed that the problem appears for x86_64 and ARM
architectures.
See attached file (test-opt-2-dim-array-iter.c) for further information.
Compilation details:
Using built-in specs.
COLLECT_GCC=i386-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../../gcc-5.1.0/configure --prefix=/usr/local/i386-eabi-5.1.0
--program-prefix=i386-eabi- --enable-languages=c,c++
--with-gmp=/usr/local/i386-eabi-5.1.0 --with-mpfr=/usr/local/i386-eabi-5.1.0
--with-mpc=/usr/local/i386-eabi-5.1.0 --with-isl=/usr/local/i386-eabi-5.1.0
--with-zlib=/usr/local --enable-lto --enable-gold
Thread model: posix
gcc version 5.1.0 (GCC)
COLLECT_GCC_OPTIONS='-O1' '-v' '-save-temps' '-o' 'test-opt-2-dim-array-iter'
'-mtune=generic' '-march=pentiumpro'
/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/cc1 -E -quiet
-v test-opt-2-dim-array-iter.c -mtune=generic -march=pentiumpro -O1
-fpch-preprocess -o test-opt-2-dim-array-iter.i
ignoring nonexistent directory
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/include
/usr/local/include
/usr/local/i386-eabi-5.1.0/include
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O1' '-v' '-save-temps' '-o' 'test-opt-2-dim-array-iter'
'-mtune=generic' '-march=pentiumpro'
/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/cc1
-fpreprocessed test-opt-2-dim-array-iter.i -quiet -dumpbase
test-opt-2-dim-array-iter.c -mtune=generic -march=pentiumpro -auxbase
test-opt-2-dim-array-iter -O1 -version -o test-opt-2-dim-array-iter.s
GNU C11 (GCC) version 5.1.0 (i686-pc-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.1.0 (i686-pc-linux-gnu)
compiled by GNU C version 5.1.0, GMP version 5.1.3, MPFR version 3.1.2,
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d06407f4e6fff3c174315d9bcdf98d85
COLLECT_GCC_OPTIONS='-O1' '-v' '-save-temps' '-o' 'test-opt-2-dim-array-iter'
'-mtune=generic' '-march=pentiumpro'
/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../i686-pc-linux-gnu/bin/as
-v --32 -o test-opt-2-dim-array-iter.o test-opt-2-dim-array-iter.s
GNU assembler version 2.25 (i686-pc-linux-gnu) using BFD version (GNU Binutils)
2.25
COMPILER_PATH=/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/libexec/gcc/i686-pc-linux-gnu/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../../i686-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/:/usr/local/i386-eabi-5.1.0/lib/gcc/i686-pc-linux-gnu/5.1.0/../../../:/lib/:/usr/lib/
[Bug tree-optimization/65217] __builtin_unreachable in if statement causes bad assembly generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65217 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law law at redhat dot com --- Resolved again :-)
[Bug other/65911] [6 Regression] r222508 breaks clang-tblgen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65911 --- Comment #6 from tbsaunde at tbsaunde dot org --- On Tue, Apr 28, 2015 at 03:59:05AM +, trippels at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65911 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-28 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- It's the ternary operator that causes the issue. The following patch works fine: huh, thanks for figuring it out! Trev
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org --- Comment #14 from prathamesh3492 at gcc dot gnu.org --- Hi, Following Maxim's suggestion I tried to build with x86_64-gcc passing -mtune=k8 at compile-time but not at link time and the same thing happens. gcc -flto -mtune=k8 foo.c -v: Without passing -mtune=k8 at link-time, -mtune=generic overrides -mtune=k8 gcc -flto foo.o -v: COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math' '-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mtune=k8' '-march=x86-64' '-v' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/cc415lAT.ltrans.out' '-fwpa' '-fresolution=/tmp/ccuL4EuS.res' /home/prathamesh.kulkarni/fsf-toolchain/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto1 -quiet -dumpbase foo.o -mtune=k8 -march=x86-64 -mtune=generic -march=x86-64 -auxbase foo -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv -fno-strict-overflow -fno-openmp -fno-openacc -fltrans-output-list=/tmp/cc415lAT.ltrans.out -fwpa -fresolution=/tmp/ccuL4EuS.res @/tmp/ccXLZx2S Passing -mtune=k8 at link-time, passes only -mtune=k8 to lto1 gcc -flto -mtune=k8 foo.o -v: COLLECT_GCC_OPTIONS='-c' '-fmath-errno' '-fsigned-zeros' '-ftrapping-math' '-fno-trapv' '-fno-strict-overflow' '-fno-openmp' '-fno-openacc' '-mtune=k8' '-march=x86-64' '-mtune=k8' '-v' '-march=x86-64' '-fltrans-output-list=/tmp/ccK0THy1.ltrans.out' '-fwpa' '-fresolution=/tmp/ccqMHR7Y.res' /home/prathamesh.kulkarni/fsf-toolchain/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto1 -quiet -dumpbase foo.o -mtune=k8 -march=x86-64 -mtune=k8 -march=x86-64 -auxbase foo -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv -fno-strict-overflow -fno-openmp -fno-openacc -fltrans-output-list=/tmp/ccK0THy1.ltrans.out -fwpa -fresolution=/tmp/ccqMHR7Y.res @/tmp/ccxcdoB1 So this looks like a target independent bug ? I am continuing to investigate it. Thank you, Prathamesh
[Bug spam/9360] 20010525035601.4254.qmail,this would be for youwe could enter that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9360 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|pending |spam Resolution|FIXED |INVALID
[Bug spam/9353] 20010525035601.4254.qmail,this would be for youwe could enter that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9353 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|pending |spam Resolution|FIXED |INVALID
[Bug spam/10531] denoxe barth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10531 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|pending |spam Resolution|FIXED |INVALID
[Bug fortran/65903] [5/6 Regression] Line continuation followed by comment character in string fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65903 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-29 Summary|Line continuation followed |[5/6 Regression] Line |by comment character in |continuation followed by |string fails to compile |comment character in string ||fails to compile Ever confirmed|0 |1 --- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- This is a regression.
[Bug tree-optimization/51513] Only partially optimizes away __builtin_unreachable switch default case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
--- Comment #7 from Peter Bergner bergner at gcc dot gnu.org ---
(In reply to Emil L from comment #3)
This optimization would be very interesting for interpreter implementators
that use a switch statement to dispatch the next instruction, when they can
guarantee that the default branch is never taken.
I have actually hit the same issue with some code from PHP, so you're not too
far off on your comment. A reduced test case from PHP looks like:
void
foo (unsigned char *ptr, unsigned int cond)
{
switch (cond)
{
case 0:
return;
case 1:
case 2:
case 3:
case 4:
case 6:
*ptr += 1;
return;
case 5:
*ptr += 2;
return;
default:
__builtin_unreachable ();
break;
}
}
In this case, the undeleted branch had a wild label that pointed to nowhere.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #18 from prathamesh3492 at gcc dot gnu.org --- Created attachment 35420 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35420action=edit patch to override default options by options in object file Hi, The following untested patch gives preference to option value in object file. In run_gcc(), options from COLLECT_GCC_OPTIONS which are taken from command line are stored in decoded_options. options from object file are stored in fdecoded_options. so override the option in decoded_options if it is present in fdecoded_options. With the patch this works: arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c arm-linux-gnueabihf-gcc test.o -flto only passes -mfpu=neon to lto1 However the patch doesn't work when same option is passed different values at compile and link-time: arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto In this case, -mfpu=neon is still passed to lto1, since the patch prefers option value from object file. Without the patch, the option from the command line was given preference. for both the following cases: arm-linux-gnueabihf-gcc test.o -flto arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16 COLLECT_GCC_OPTIONS contains -mfpu=vfpv3-d16, however in the first case it isn't explictly passed by user, so passing -mfpu=neon would be correct. In the second case, since -mfpu=vfpv3-d16 is passed intentionally by user, should it be considered as an error - conflicting options ? Unfortunately, it looks like there is no way to distinguish between options defined by default and explicitly passed options from COLLECT_GCC_OPTIONS and that's the only way command line options are passed to lto-wrapper from the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to indicate which options were explicitly passed from command line. For instance, additionally COLLECT_GCC_OPTIONS would contain -mfpu=vfpv3-d16-explicit to indiciate that -mfpu=vfpv3-d16 was passed from command line and not set by default. In lto-wrapper the options could be parsed to check if they have explicit suffix and thus distinguish between explicit and defualt defined options. Does that sound reasonable ? I would be grateful for suggestions. Thank you, Prathamesh
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 --- Comment #30 from Jürgen Reuter juergen.reuter at desy dot de --- I can apply this patch on r222550 of https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/ correct?
[Bug c++/65896] [5/6 Regression] Erroneous uninitialized variable access error in constexpr function with temporary variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65896 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 29 00:57:50 2015 New Revision: 222557 URL: https://gcc.gnu.org/viewcvs?rev=222557root=gccview=rev Log: PR c++/65896 * constexpr.c (cxx_eval_store_expression): Don't try to actually store an empty class. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-empty9.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug c++/65896] [5/6 Regression] Erroneous uninitialized variable access error in constexpr function with temporary variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65896 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |5.2 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.2, 6
[Bug middle-end/65922] New: Switch statement with __builtin_unreachable creates a wild branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65922 Bug ID: 65922 Summary: Switch statement with __builtin_unreachable creates a wild branch Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- The following test case compiled with -O2 creates a wild branch when it generates the branch to the switch's default leg. On both POWER and x86_64 (maybe others), it generates a branch with a label just past the last instruction in the function. POWER: .L.foo: cmplwi 7,4,6 bgt 7,.L2 [snip] blr .p2align 4,,15 .L2: .long 0 X86_64: foo: .LFB0: .cfi_startproc cmpl$6, %esi ja .L2 [snip] ret .p2align 4,,10 .p2align 3 .L2: .cfi_endproc .LFE0: .size foo, .-foo My guess is that since we've stated that the default leg is unreachable, we should probably just delete the branch altogether, rather than allowing it to branch into nowhere. I'll note that I see the same behavior from GCC 4.8 thru trunk. The code from GCC 4.7 and earlier looks ok.
[Bug c++/65876] [5/6 Regression] [C++11] ICE in cxx_eval_call_expression, at cp/constexpr.c:1358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65876 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/65922] Switch statement with __builtin_unreachable creates a wild branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65922
Peter Bergner bergner at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.7.0
Known to fail||4.8.0, 4.9.0, 5.1.0, 6.0
--- Comment #1 from Peter Bergner bergner at gcc dot gnu.org ---
The last tree dump looks ok to me:
foo (unsigned char * ptr, unsigned int cond)
{
unsigned char _5;
unsigned char _6;
unsigned char _8;
unsigned char _9;
bb 2:
switch (cond_2(D)) default: L7, case 0: L9, case 1 ... 4: L1, case 5:
L6, case 6: L1
L1:
_5 = *ptr_4(D);
_6 = _5 + 1;
*ptr_4(D) = _6;
goto bb 6 (L9);
L6:
_8 = *ptr_4(D);
_9 = _8 + 2;
*ptr_4(D) = _9;
goto bb 6 (L9);
L7:
__builtin_unreachable ();
L9:
return;
}
But the first rtl code after expand looks suspect to me.
[Bug target/65915] New: [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65915
Bug ID: 65915
Summary: [6 Regression] FAIL:
gcc.target/i386/avx512f-vrndscalepd-2.c (internal
compiler error)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: tocarip.intel at gmail dot com
Target Milestone: ---
On x86-64, r222470 caused:
[hjl@gnu-ivb-1 gcc]$ ./xgcc -B./
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c
-fpic -mcmodel=medium -fno-diagnostics-show-caret -fdiagnostics-color=never
-O2 -mavx512f -S
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c:
In function \u2018test_512\u2019:
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c:101:1:
error: insn does not satisfy its constraints:
(insn 367 366 319 9 (set (reg:V2DF 53 xmm16 [ D.29386 ])
(vec_merge:V2DF (vec_duplicate:V2DF (float:DF (reg:SI 2 cx [orig:96
D.29385 ] [96])))
(reg:V2DF 53 xmm16 [ D.29386 ])
(const_int 1 [0x1]))) 2191 {sse2_cvtsi2sd}
(expr_list:REG_DEAD (reg:SI 2 cx [orig:96 D.29385 ] [96])
(nil)))
/export/gnu/import/git/gcc-regression/gcc/gcc/testsuite/gcc.target/i386/avx512f-vrndscalepd-2.c:101:1:
internal compiler error: in extract_constrain_insn, at recog.c:2244
0xcf4a34 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../../gcc/gcc/rtl-error.c:110
0xcf4a94 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../../../gcc/gcc/rtl-error.c:121
0xca7059 extract_constrain_insn(rtx_insn*)
../../../../gcc/gcc/recog.c:2244
0xcb5847 copyprop_hardreg_forward_1
../../../../gcc/gcc/regcprop.c:793
0xcb704b execute
../../../../gcc/gcc/regcprop.c:1289
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.
[hjl@gnu-ivb-1 gcc]$
[Bug target/65914] New: [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 Bug ID: 65914 Summary: [6 Regression] error: unrecognizable insn Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-unknown-linux-gnu Target: powerpc64le-unknown-linux-gnu Build: powerpc64le-unknown-linux-gnu Running the Boost testsuite on ppc64le shows: trippels@gcc2-power8 status % g++ -O3 -c -std=c++14 unordered_set_test.ii ../libs/intrusive/test/unordered_set_test.cpp: In static member function ‘static void test_unordered_setValueTraits, CacheBegin, CompareHash, Incremental::test_rehash(std::vectortypename ValueTraits::value_type, boost::move_detail::true_) [with ValueTraits = boost::intrusive::mhtraitsboost::intrusive::testvaluehooksvoid*, false, boost::intrusive::unordered_set_member_hookboost::intrusive::void_pointervoid*, boost::intrusive::optimize_multikeytrue, void, void, boost::intrusive::testvaluehooksvoid*, false::node_; bool CacheBegin = false; bool CompareHash = false; bool Incremental = true; typename ValueTraits::value_type = boost::intrusive::testvaluehooksvoid*, false; boost::move_detail::true_ = boost::move_detail::bool_true]’: ../libs/intrusive/test/unordered_set_test.cpp:448:1: error: unrecognizable insn: } ^ (insn 72 71 73 2 (set (reg:V2DI 540 [ vect_cst_.26426 ]) (vec_concat:V2DI (reg/f:DI 150 virtual-stack-vars [ D.668853 ]) (reg:DI 541 [ D.668853 ]))) ../boost/intrusive/detail/slist_node.hpp:55 -1 (nil)) ../libs/intrusive/test/unordered_set_test.cpp:448:1: internal compiler error: in extract_insn, at recog.c:2341 0x109a7e33 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:110 0x109a7eaf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../gcc/gcc/rtl-error.c:118 0x1096d767 extract_insn(rtx_insn*) ../../gcc/gcc/recog.c:2341 0x106c98bb instantiate_virtual_regs_in_insn ../../gcc/gcc/function.c:1598 0x106c98bb instantiate_virtual_regs ../../gcc/gcc/function.c:1966 0x106c98bb execute ../../gcc/gcc/function.c:2015 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. Reducing...
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 35411 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35411action=edit Prototype patch for bextr and bzhi Prototype patch that removes flag checks for bextr and bzhi insns.
[Bug libstdc++/60333] type_traits make_signed, make_unsigned missing support for long long enumerations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60333 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Apr 28 13:21:54 2015 New Revision: 222526 URL: https://gcc.gnu.org/viewcvs?rev=222526root=gccview=rev Log: PR libstdc++/60333 * include/std/type_traits (__make_unsigned_selector_Tp, false, true): Handle enumeration types larger than sizeof(long). (__make_signed_selector_Tp, false, true): Find unsigned type then make it signed. * testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error. * testsuite/20_util/make_signed/requirements/typedefs_neg.cc: Likewise. * testsuite/20_util/make_signed/requirements/typedefs-3.cc: New. * testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc: Adjust dg-error. * testsuite/20_util/make_unsigned/requirements/typedefs-3.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-3.cc trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-3.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc trunk/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc trunk/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65915 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Total regressions with -fpic -mcmodel=medium are: FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error) FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (test for excess errors) FAIL: gcc.target/i386/avx512f-vrndscaleps-2.c (internal compiler error) FAIL: gcc.target/i386/avx512f-vrndscaleps-2.c (test for excess errors) FAIL: gcc.target/i386/avx512vl-vrndscaleps-2.c (internal compiler error) FAIL: gcc.target/i386/avx512vl-vrndscaleps-2.c (test for excess errors)
[Bug libgcc/62097] mipsel-sde-elf build fails on OS X 10.7 host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62097 Paul Waring paul at xk7 dot net changed: What|Removed |Added CC||paul at xk7 dot net --- Comment #3 from Paul Waring paul at xk7 dot net --- I can confirm the same issue occurs for me on OS X 10.10 (Yosemite) and the following: GCC: 4.9.2 binutils: 2.25 MPFR: 3.1.2 MPC: 1.0.3 GMP: 6.0.0a Newlib: 2.2.0-1 clang --version Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix Is there anything I can do to help fix this bug?
[Bug libstdc++/65913] Linking failure without -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This is due to the changes for Bug 65033
[Bug libstdc++/60333] type_traits make_signed, make_unsigned missing support for long long enumerations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60333 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #10 from Jürgen Reuter juergen.reuter at desy dot de --- (In reply to Dominique d'Humieres from comment #9) With the attached patch your small test case and the test suite runs w/o segfault now. Furthermore does gcc6 bootstrap and regtest ok with the patch. Confirmed. The bigger test in comment 2 runs without segfault also. However I get an ICE when compiling the full package at http://whizard.hepforge.org/versions/unofficial/whizard-2.2.6_alpha-20150426. tar.gz libtool: compile: gfc -I../basics -I../utilities -I../testing -I../system -I../combinatorics -I../expr_base -I../physics -g -O2 -c evaluators.f90 -fno-common -o .libs/evaluators.o evaluators.f90:897:0: .or. qn_mask_rest 1 internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:9203 I confirm this ICE with the patch and will provide a smaller test case soon.
[Bug c/65916] New: Unnecessary floating-point instruction causes runtime exception on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65916
Bug ID: 65916
Summary: Unnecessary floating-point instruction causes runtime
exception on PowerPC
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nikolay.pakulin at gmail dot com
Target Milestone: ---
Created attachment 35412
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35412action=edit
Test case to reproduce the issue
Writing 64-bit integers to memory on 32-bit PPC involves floating point
register FP0. When floating-point support is disabled (bit FP is cleared in
MSR register) the generated code leads to exception FP unavailable interrupt.
The test case compiled by GCC cross compiler running on x86_64 Linux.
powerpc-elf-gcc -S -m32 -mcpu=e500mc uint64.c
-- uint64.c --
typedef unsigned long long u64;
u64 globvar;
void f(u64 arg) {
globvar = arg;
}
-- /uint64.c --
-- Generated ASM --
f:
stwu 1,-32(1)
stw 31,28(1)
mr 31,1
stw 3,8(31) # Copies 'arg' to the temporary on the stack
stw 4,12(31)#
lis 9,globvar@ha
la 9,globvar@l(9)
lfd 0,8(31) # Loads the temporary to FP0 -- exception!
stfd 0,0(9) # Store FP0 to memory
addi 11,31,32
lwz 31,-4(11)
mr 1,11
blr
-- End of Generated ASM --
== GCC specs ==
Using built-in specs.
COLLECT_GCC=powerpc-elf-gcc
COLLECT_LTO_WRAPPER=/opt/crosstools/powerpc-elf-4.9.1-Linux-x86_64/bin/../libexec/gcc/powerpc-elf/4.9.1/lto-wrapper
Target: powerpc-elf
Configured with: ../gcc-4.9.1/configure --target=powerpc-elf
--prefix=/home/geist/svn/toolchains/powerpc-elf-4.9.1-Linux-x86_64
--enable-languages=c,c++ --disable-werror
Thread model: single
gcc version 4.9.1 (GCC)
== End of GCC specs ==
The workaround is to compile with optimization turned on. With -O switch GCC
produces ASM without FP0:
powerpc-elf-gcc -S -m32 -mcpu=e500mc -O uint64.c
-- Generated optimized ASM --
f:
lis 9,globvar@ha
la 9,globvar@l(9)
stw 3,0(9)# direct write to the destination
stw 4,4(9)#
blr
-- End of generated optimized ASM --
[Bug libstdc++/61645] forward_list::splice_after shall not throw exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61645 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- done
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-28 Ever confirmed|0 |1 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to James Almer from comment #1) The same apparently happens with bextr, blsi, blsr, and most (if not all) of AMD's tbm instructions. They set the ZF flag but gcc still generates a test instruction. Please see the patch, attached in Comment #2. While I can see the use (and benefit) to model the patterns that also set CC register internally for BEXTR and BZHI instructions, I don't think other listed instructions have clear usage scenarios to warrant additional patterns. Can you perhaps show the benefit to have more insns modelled this way?
[Bug libstdc++/61645] forward_list::splice_after shall not throw exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61645 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Apr 28 13:05:33 2015 New Revision: 222525 URL: https://gcc.gnu.org/viewcvs?rev=222525root=gccview=rev Log: PR libstdc++/61645 * include/bits/forward_list.h (forward_list::splice_after): Add noexcept. * include/bits/forward_list.tcc (forward_list::splice_after): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/forward_list.h trunk/libstdc++-v3/include/bits/forward_list.tcc
[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target||arm-eabi --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org --- The standard headers should only be defining bool if stdbool.h has been included. So this looks more like a build environment error than a bug in GCC.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #19 from prathamesh3492 at gcc dot gnu.org --- (In reply to prathamesh3492 from comment #18) Created attachment 35420 [details] patch to override default options by options in object file Hi, The following untested patch gives preference to option value in object file. In run_gcc(), options from COLLECT_GCC_OPTIONS which are taken from command line are stored in decoded_options. options from object file are stored in fdecoded_options. so override the option in decoded_options if it is present in fdecoded_options. With the patch this works: arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c arm-linux-gnueabihf-gcc test.o -flto only passes -mfpu=neon to lto1 However the patch doesn't work when same option is passed different values at compile and link-time: arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto In this case, -mfpu=neon is still passed to lto1, since the patch prefers option value from object file. Without the patch, the option from the command line was given preference. for both the following cases: arm-linux-gnueabihf-gcc test.o -flto arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16 COLLECT_GCC_OPTIONS contains -mfpu=vfpv3-d16, however in the first case it isn't explictly passed by user, so passing -mfpu=neon would be correct. In the second case, since -mfpu=vfpv3-d16 is passed intentionally by user, should it be considered as an error - conflicting options ? Unfortunately, it looks like there is no way to distinguish between options defined by default and explicitly passed options from COLLECT_GCC_OPTIONS and that's the only way command line options are passed to lto-wrapper from the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to indicate which options were explicitly passed from command line. For instance, additionally COLLECT_GCC_OPTIONS would contain -mfpu=vfpv3-d16-explicit to indiciate that -mfpu=vfpv3-d16 was passed from command line and not set by default. In lto-wrapper the options could be parsed to check if they have explicit suffix and thus distinguish between explicit and defualt defined options. Does that sound reasonable ? I would be grateful for suggestions. Instead of modifying COLLECT_GCC_OPTIONS, maybe create another environment variable say COLLECT_GCC_OPTIONS_EXPLICIT and if an option is passed on command line, put it in COLLECT_GCC_OPTIONS_EXPLICIT, so lto-wrapper can distinguish between default defined options and options passed on command line. Thank you, Prathamesh Thank you, Prathamesh
[Bug tree-optimization/51513] Only partially optimizes away __builtin_unreachable switch default case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 65922 has been marked as a duplicate of this bug. ***
[Bug middle-end/65922] Switch statement with __builtin_unreachable creates a wild branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65922 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 51513. *** This bug has been marked as a duplicate of bug 51513 ***
[Bug middle-end/65922] Switch statement with __builtin_unreachable creates a wild branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65922
Peter Bergner bergner at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Peter Bergner bergner at gcc dot gnu.org ---
Closing as a DUP. I forgot to include the test case, so for posterity, here is
the test case reduced from PHP.
void
foo (unsigned char *ptr, unsigned int cond)
{
switch (cond)
{
case 0:
return;
case 1:
case 2:
case 3:
case 4:
case 6:
*ptr += 1;
return;
case 5:
*ptr += 2;
return;
default:
__builtin_unreachable ();
break;
}
}
[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #3 from Jeffrey A. Law law at redhat dot com --- if (_8 != _14) goto bb 3; else goto bb 6; bb 3: target_bb.1_15 = target_bb; if (_14 == target_bb.1_15) goto bb 4; else goto bb 6; bb 4: if (_8 != target_bb.1_15) goto bb 5; else goto bb 6; Presumably depending on the ordering in the conditionals, we should discover that in bb4 _8 and _15 are equal and eliminate the test.
[Bug libstdc++/65913] Linking failure without -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #2 from Richard Henderson rth at gcc dot gnu.org --- Created attachment 35416 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35416action=edit proposed patch jwakely suggested on irc reverting the -alignment fake pointer for the integral type template. Note that there are weird targets that have non-power-of-two integral types: config/avr/avr-modes.def:FRACTIONAL_INT_MODE (PSI, 24, 3); Thankfully, avr doesn't also have atomic operations on this type, so the second part of fold_builtin_atomic_always_lock_free would fail. But I think we can also do better for non-integral types, so it's probably better to attack this inside the compiler.
[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- r222492 is still failing.
[Bug c++/65734] Yet another case of lost alignment by stor_layout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65734 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug target/65914] [6 Regression] error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r222514 so possibly a latent issue.
[Bug bootstrap/11660] libffi only builds when java is selected as language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11660 Eric Gallager egall at gwmail dot gwu.edu changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #11 from Eric Gallager egall at gwmail dot gwu.edu --- Doesn't libffi also get built if go is selected as a language? I can't verify it for myself due to bug 46986, but based on my reading of Makefile.def, it seems like building libgo should cause libffi to be built, as well...
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #43 from James Greenhalgh jgreenhalgh at gcc dot gnu.org ---
(In reply to torvald from comment #37)
(In reply to James Greenhalgh from comment #35)
(In reply to torvald from comment #32)
(In reply to James Greenhalgh from comment #28)
This also gives us an easier route to fixing any issues with the
acquire/release __sync primitives (__sync_lock_test_and_set and
__sync_lock_release) if we decide that these also need to be stronger
than
their C++11 equivalents.
I don't think we have another case of different __sync vs. __atomics
semantics in case of __sync_lock_test_and_set. The current specification
makes it clear that this is an acquire barrier, and how it describes the
semantics (ie, loads and stores that are program-order before the acquire
op
can move to after it) , this seems to be consistent with the effects C11
specifies for acquire MO (with perhaps the distinction that C11 is clear
that acquire needs to be paired with some release op to create an ordering
constraint).
I think that the question is which parts of a RMW operation with
MEMMODEL_ACQUIRE semantics is ordered. My understanding is that in C++11
MEMMODEL_ACQUIRE only applies to the load half of the operation. So an
observer to:
atomic_flag_test_and_set_explicit(foo, memory_order_acquire)
atomic_store_exlicit (bar, 1, memory_model_relaxed)
That depends on your observer. When reasoning about C11, please let's use
complete examples (and ideally, run them through cppmem). For example, if
the observation is done by a pair of relaxed-MO loads, bar==1 foo==0 can
be observed:
int main() {
atomic_int foo = 0;
atomic_int bar = 0;
{{{ {
r1 = cas_strong(foo, 0, 1);
bar.store(1, memory_order_relaxed);
} ||| {
r2 = bar.load(memory_order_relaxed).readsvalue(1);
r3 = foo.load(memory_order_relaxed).readsvalue(0);
} }}};
return 0; }
Thanks for that, and sorry again for my sloppy terminology. I did try to write
a
cppmem example, but I couldn't find the syntax for a CAS. If I could have, this
is
what I would have written, and gets the results I had expected and was trying
to express.
Is permitted to observe a write to bar before a write to foo (but not before
the read from foo).
How does one observe a load in C11 (ie, so that before the read from foo
is defined)? You can constrain the reads-from of a load, but the load
itself is not observable as an effect.
Sorry, this is ARM memory model terminology leaking across to my C11 examples,
but
even then what I was saying doesn't make sense. To observe a load in the ARM
model:
A read of a location in memory is said to be observed by an observer when a
subsequent write to the location by the same observer has no effect on the
value
returned by the read.
But you are right, this is not interesting to model.
I think I get what you're trying to say regarding the load half but I
would phrase it differently: If there could be another release store to foo
that the CAS/TAS reads-from, then moving the store to bar before the load
would risk creating a cycle between inter-thread happens-before and
sequenced-before-created intra-thread happens-before. (Note that the later
isn't visible to other threads though, except through additional
inter-thread synchronization.)
Perhaps one could also say that moving the store to bar before the store to
foo could result in the CAS/TAS not being atomic -- but this is just
reliably observable if the foo observation is a CAS/TAS by itself (so it's
totally ordered with the other CAS), or if there is a inter-thread
happens-before between the observation of bar and the store to bar (which
means using a release store for bar).
I'm discussing these aspects because I think it matters which observations
are actually possible in a reliable way. It matters for C11, and it may
matter for the __sync semantics as well because while the __sync functions
promise TSO, we don't really do so for all (nonatomic) loads or stores
anywhere else in the program...
IOW, can we actually come up with reliable and correct counter-examples
(either using the C11 or __sync interfaces) for the guarantees we think ARM
might not provide?
My reading of the Itanium ABI is that the acquire barrier applies to the
entire operation (Andrew, I think you copied these over exactly backwards in
comment 34 ;) ):
Disallows the movement of memory references to visible data from
after the intrinsic (in program order) to before the intrinsic (this
behavior is desirable at lock-acquire operations, hence the name).
The definition of __sync_lock_test_and_set is:
Behavior:
• Atomically store the supplied value in *ptr and return the old value
of *ptr. (i.e.)
{ tmp = *ptr; *ptr = value; return tmp; }
• Acquire barrier.
Hmm. I don't
[Bug tree-optimization/65918] Optimized code ( -O0) on 2-dim array iteration incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65918 --- Comment #3 from J. W. Mitchell habanero_pizza at yahoo dot com --- Indeed. Apologies for the submission
[Bug c++/65923] New: False positive for warning about literal operator suffix and using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923 Bug ID: 65923 Summary: False positive for warning about literal operator suffix and using Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: arnetheduck at gmail dot com Target Milestone: --- In the following snippet, a warning is given when bringing a chrono literal into the global namespace explicity, but not when importing all literals. Looks like the warning shouldn't be there, since the two do the same thing, and using directives are the way to go with literal operators. cat /tmp/tmp.cc: #include chrono using std::literals::chrono_literals::operators; // warning here using std::literals; // no warning here /usr/local/gcc49/bin/g++ -c -std=c++14 /tmp/tmp.cc: /tmp/tmp.cc:4:47: warning: literal operator suffixes not preceded by ‘_’ are reserved for future standardization using std::literals::chrono_literals::operators; // warning here
[Bug tree-optimization/65917] [6.0 regression] FAIL: gcc.dg/tree-ssa/20030922-2.c scan-tree-dump-times dom1 if 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65917 --- Comment #4 from Jeffrey A. Law law at redhat dot com --- We'll probably need to XFAIL this for now. This is definitely a case where we were just getting lucky before and the new code to canonicalize the comparison arguments causes us not to get lucky. The single use heuristic doesn't help here, because both operands have multiple uses. I'd pondered walking up the use-def chains to guess which operand is more expensive to compute and use that as a heuristic as well, but in this case it'd do the opposite of what we want. I don't see other obvious heuristics that would resolve this issue. The right way to fix this would be to unify cprop and simplification -- ie, when we have a statement that references an SSA_NAME with one of these equivalences, we need to try both SSA_NAMEs and see if it simplifies. I've avoided doing that simply because it hasn't seemed worth the effort and compile-time cost.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #19 from Markus Trippelsdorf trippels at gcc dot gnu.org --- See for example: http://thread.gmane.org/gmane.comp.gnu.binutils.bugs/19841/focus=19855 When this thread is displayed in mutt the highlighted messages appears in the wrong place.
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- The rule certainly has nothing to do with whether the struct types are defined inside the union definition, or defined outside and then used inside via a tag or typedef. The it is permitted wording is poorly defined, and the C99 changes confused this through failing to realise how it's poorly defined. In C90, the paragraph starts With one exception, if a member of a union object is accessed after a value has been stored in a different member of the object, the behavior is implementation-defined.[41] One special guarantee is made ... it is permitted This reads to me like it is permitted was intended as an exception to the general rule of behavior being implementation-defined (that is, it was defining one case of type punning, which was more generally defined non-normatively in the footnote added in C99 TC3). The difficulty with it is permitted is there are any number of cases where other wording indicates something is not permitted that it could be interpreted as overriding - just saying it is permitted fails to say which are or are not overridden. (As a C11 example, something might not be permitted because it's a data race, for example, but accessing a common initial sequence can hardly be intended to override the normal rules about data races.) So the authors of N685 read it is permitted as relating not to the previous sentence in the same paragraph about accessing different union members, but as relating to completely separate rules about aliasing. The visible union rule was then inserted for C99, thereby serving to confuse things further by supporting the suggestion that it is permitted relates to aliasing. DR#236 then considered a different case of aliasing through pointers to union members. However, the response never decided the question of whether the accesses must visibly be through the union, or whether it's sufficient for the declaration of the union to be visible. Basing things on whether a union is visible in the translation unit is clearly a bad rule because of action-at-a-distance effects (the visible union might be in a header included for some completely unrelated purpose, but would still inhibit optimization). (Note that the exact example given in this bug is invalid as the union has active member s1, but is modified via member s2; you can only inspect common members of non-active union members, not modify them. But presumably using .s2 in the initializer would still show the issue.) Thus, it is permitted needs reworking to describe what it's an exception to. To the extent that it's an exception to aliasing rules, I think that should only be where the union is actually used for the accesses in question (in which case no exception is actually needed beyond defining the layout requirements and making the type punning rules normative), and DR#236 should be clarified accordingly.
[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65871 --- Comment #4 from James Almer jamrial at gmail dot com --- (In reply to Uroš Bizjak from comment #3) Please see the patch, attached in Comment #2. While I can see the use (and benefit) to model the patterns that also set CC register internally for BEXTR and BZHI instructions, I don't think other listed instructions have clear usage scenarios to warrant additional patterns. Can you perhaps show the benefit to have more insns modelled this way? Not really, i simply assumed that taking into consideration what flags these instructions affected in every case was the intended behavior, so figured it was worth pointing them out. I'm mainly interested in bzhi (and by extension bextr).
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #18 from Markus Trippelsdorf trippels at gcc dot gnu.org --- One thing I've noticed is that the emails to gcc-bugs now use the local time of the user. So the sorting isn't correct anymore if people from different time zones comment. (The same issue also happens on sourceware.org/bugzilla/)
[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894 --- Comment #11 from Jürgen Reuter juergen.reuter at desy dot de --- Here is the small test case for the ICE with the patch provided Andre Vehreschild: gfortran -c evaluators.f90 evaluators.f90:40:0: .or. qn_mask_rest 1 internal compiler error: in gfc_trans_assignment_1, at fortran/trans-expr.c:9187 evaluators.f90:40:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) This is the code: module evaluators implicit none private type :: quantum_numbers_mask_t contains generic :: operator(.or.) = quantum_numbers_mask_or procedure, private :: quantum_numbers_mask_or end type quantum_numbers_mask_t type :: index_map_t integer, dimension(:), allocatable :: entry end type index_map_t type :: prt_mask_t logical, dimension(:), allocatable :: entry end type prt_mask_t type :: qn_mask_array_t type(quantum_numbers_mask_t), dimension(:), allocatable :: mask end type qn_mask_array_t contains elemental function quantum_numbers_mask_or (mask1, mask2) result (mask) type(quantum_numbers_mask_t) :: mask class(quantum_numbers_mask_t), intent(in) :: mask1, mask2 end function quantum_numbers_mask_or subroutine make_product_interaction (prt_is_connected, qn_mask_in, qn_mask_rest) type(prt_mask_t), dimension(2), intent(in) :: prt_is_connected type(qn_mask_array_t), dimension(2), intent(in) :: qn_mask_in type(quantum_numbers_mask_t), intent(in) :: qn_mask_rest type(index_map_t), dimension(2) :: prt_index_in integer :: i type(quantum_numbers_mask_t), dimension(:), allocatable :: qn_mask allocate (qn_mask (2)) do i = 1, 2 qn_mask(prt_index_in(i)%entry) = pack (qn_mask_in(i)%mask, prt_is_connected(i)%entry) .or. qn_mask_rest end do end subroutine make_product_interaction end module evaluators
Re: [Bug rtl-optimization/65912] New: x_rtl.x_frame_offset not updated after frame related insn deleted
On Apr 27, 2015, at 9:10 PM, jiwang at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: Has anyone run into this issue on other architecture like MIPS, PPC? Yes on both.
[Bug rtl-optimization/65912] x_rtl.x_frame_offset not updated after frame related insn deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65912 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com --- On Apr 27, 2015, at 9:10 PM, jiwang at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: Has anyone run into this issue on other architecture like MIPS, PPC? Yes on both.
[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65910 --- Comment #4 from Caroline Tice cmtice at google dot com --- Has anyone actually committed this fix? I'm not seeing it in my tree yet
[Bug c/65920] New: Not able to compile a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65920 Bug ID: 65920 Summary: Not able to compile a code Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: imran.siddiqui at live dot com Target Milestone: --- Created attachment 35418 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35418action=edit Error I got an upgrade in AIX server i.e. 7.1 with the DB2 version 9.5. Whenever we complied a legacy C code in previous AIX server i.e 5.3 with Db2 version 9.5 and GCC version 2.9 it worked fined. But now i am facing issues in compling.It is very critical for my project to solve this.. I am attaching some errors
[Bug c++/65920] Not able to compile a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65920 Imran imran.siddiqui at live dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Imran imran.siddiqui at live dot com --- Thans for the quick reply. The code is perfectly fine as it was workinng as i mentioned earlier But after the upgrade only it started throwing the error. I tried repalcing char * with string in the log.cpp..but again it left me some other errors
[Bug tree-optimization/65887] remove va_arg ap copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65887 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from vries at gcc dot gnu.org --- Patch committed, marking resolved - fixed.
[Bug fortran/65921] New: GFortran should use __builtin_mul_overflow when checking allocation sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65921 Bug ID: 65921 Summary: GFortran should use __builtin_mul_overflow when checking allocation sizes Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org Target Milestone: --- As of the GCC-5 release there is a new __builtin_mul_overflow builtin (https://gcc.gnu.org/gcc-5/changes.html ). GFortran could use this instead of the current overflow checks 1) In the frontend, code generated for the ALLOCATE statement. 2) In libgfortran/runtime/memory.c (xmallocarray).
[Bug c++/65896] [5/6 Regression] Erroneous uninitialized variable access error in constexpr function with temporary variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65896 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Apr 28 21:27:17 2015 New Revision: 222549 URL: https://gcc.gnu.org/viewcvs?rev=222549root=gccview=rev Log: PR c++/65896 * constexpr.c (cxx_eval_store_expression): Don't try to actually store an empty class. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-empty9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #10 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Apr 28, 2015 at 05:32:11PM +, joseph at codesourcery dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- Fixed in glibc (commit 7d0b2575416aec2717e8665287d0ab77826a0ade). I'd advise merging to trunk GCC libquadmath all relevant glibc changes since the last merges in 2012, rather than cherry-picking just this fix (although if you wish to fix things on release branches, cherry-picking just the critical fixes would be appropriate there). Short of grabbing the entire glibc repository, how does one grab the current libquadmath code? In particular, gitweb suggests that there isn't a component of glibc with the name libquadmath.
[Bug c/65920] Not able to compile a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65920 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Severity|critical|normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Sounds like you don't know that string is now in the std namespace. Either add using std::string; after the include of string.h or change all references to string to std::string. You need to figure out where LogFile is defined and compile that c++ file too. This is not a GCC bug but rather an issue with your code. If you want to ask C++ questions it is best to ask on a different place than here. Also how to use gcc it would be best to ask on gcc-h...@gcc.gnu.org rather than in a bug report.
[Bug tree-optimization/65887] remove va_arg ap copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65887 --- Comment #5 from vries at gcc dot gnu.org --- Author: vries Date: Tue Apr 28 20:58:51 2015 New Revision: 222546 URL: https://gcc.gnu.org/viewcvs?rev=222546root=gccview=rev Log: Remove ifn_va_arg ap fixup 2015-04-28 Tom de Vries t...@codesourcery.com PR tree-optimization/65887 * gimplify.c (gimplify_modify_expr): Remove ifn_va_arg ap fixup. * c-common.c (build_va_arg): Mark va_arg ap argument as addressable. Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/gimplify.c
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #11 from joseph at codesourcery dot com joseph at codesourcery dot com --- I don't know what process Jakub and Tobias used (a) to identify relevant files / changes in glibc and (b) to make all the changes to operate on __float128 rather than long double. Roughly, it's sysdeps/ieee754/ldbl-128, *plus* strtod-related files from stdlib/, *plus* printf-related files from stdio-common, *plus* some functions (especially complex.h functions) from math/, that are used in libquadmath and so may need updating for changes made in glibc.
[Bug c++/65920] Not able to compile a code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65920 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- well GCC 2.9 was not standard complaint with respect of C++ STL so the string class was not part of the std namespace. But that changed with 3.0 which was over 10 years ago now. Again this is not a question about a GCC bug but rather a standard C++ question.
[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Attachment #35318|0 |1 is obsolete|| --- Comment #29 from vehre at gcc dot gnu.org --- Created attachment 35419 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35419action=edit Candidate patch for latest regressions. Juergen, please test.
[Bug c/65901] no warning or error for va_arg (ap, void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65901 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Apr 28 08:36:50 2015 New Revision: 222515 URL: https://gcc.gnu.org/viewcvs?rev=222515root=gccview=rev Log: PR c/65901 * c-typeck.c (c_build_va_arg): Require TYPE be a complete type. * gcc.c-torture/compile/pr48767.c (foo): Add dg-error. * gcc.dg/pr65901.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr65901.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr48767.c
[Bug c/65901] no warning or error for va_arg (ap, void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65901 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed for GCC 6.
[Bug target/65832] Inefficient vector construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Another example where the vectorizer thinks vectorization is profitable:
#define N 16
unsigned int out[N];
unsigned int in[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
__attribute__ ((noinline)) int
main1 (unsigned int x, unsigned int y)
{
int i;
unsigned int a0, a1, a2, a3;
a0 = in[0];
a1 = in[1];
a2 = in[2];
a3 = in[3];
out[0] = a0 * x;
out[1] = a1 * y;
out[2] = a2 * x;
out[3] = a3 * y;
}
generates
main1:
.LFB0:
.cfi_startproc
movl%edi, -12(%rsp)
movd-12(%rsp), %xmm0
movl%esi, -12(%rsp)
movd-12(%rsp), %xmm3
movdqa in(%rip), %xmm2
punpckldq %xmm3, %xmm0
psrlq $32, %xmm2
punpcklqdq %xmm0, %xmm0
movdqa %xmm0, %xmm1
psrlq $32, %xmm0
pmuludq %xmm2, %xmm0
pshufd $8, %xmm0, %xmm0
pmuludq in(%rip), %xmm1
pshufd $8, %xmm1, %xmm1
punpckldq %xmm0, %xmm1
movaps %xmm1, out(%rip)
ret
slightly less obfuscated when we allow gpr xmm moves with -mtune=intel:
main1:
.LFB0:
.cfi_startproc
movd%edi, %xmm0
movd%esi, %xmm3
movdqa in(%rip), %xmm2
punpckldq %xmm3, %xmm0
punpcklqdq %xmm0, %xmm0
psrlq $32, %xmm2
movdqa %xmm0, %xmm1
psrlq $32, %xmm0
pmuludq in(%rip), %xmm1
pmuludq %xmm2, %xmm0
pshufd $8, %xmm1, %xmm1
pshufd $8, %xmm0, %xmm0
punpckldq %xmm0, %xmm1
movdqa %xmm1, out(%rip)
ret
so for { x, y, x, y } construction we generate
movd%edi, %xmm0
movd%esi, %xmm3
punpckldq %xmm3, %xmm0
punpcklqdq %xmm0, %xmm0
no f*** idea where all the shifting and shuffling comes from...
This is just
vect_cst_.7_18 = {x_6(D), y_9(D), x_6(D), y_9(D)};
vect_a0_2.5_17 = MEM[(unsigned int *)in];
vect__7.6_19 = vect_a0_2.5_17 * vect_cst_.7_18;
MEM[(unsigned int *)out] = vect__7.6_19;
[Bug target/65832] Inefficient vector construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65832 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Somehow we get into very weird initial RTL generated by expand... (insn 12 11 13 (set (reg:V2DI 101) (mult:V2DI (zero_extend:V2DI (vec_select:V2SI (reg:V4SI 95 [ vect_cst_.7 ]) (parallel [ (const_int 0 [0]) (const_int 2 [0x2]) ]))) (zero_extend:V2DI (vec_select:V2SI (mem/c:V4SI (reg/f:DI 94) [1 MEM[(unsigned int *)in]+0 S16 A256]) (parallel [ (const_int 0 [0]) (const_int 2 [0x2]) ]) t.c:17 -1 (nil)) (WTF!? As if there were no integer vector multiply with SSE2 but only DImode ones?!)
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) For h we get into the loop PHI handling code which drops to INF-1 if it iterates too much. The rest probably ripples down from that. I can't see where that [1, 0x7ff] issue happens. Current trunk, -O2 -fdump-tree-vrp-details on the testcase has in vrp1 dump: bb 2: g.0_9 = g; if (g.0_9 0) goto bb 3; else goto bb 9; bb 3: _12 = -g.0_9; i_13 = (long int) _12; goto bb 9; and Visiting statement: _12 = -g.0_25; Found new range for _12: [1, +INF(OVF)] marking stmt to be not simulated again Visiting statement: i_13 = (long int) _12; Found new range for i_13: [1, +INF(OVF)] marking stmt to be not simulated again The point was that the cast from 32-bit signed to 64-bit signed also should imply that the value is not bigger than INT_MAX, and that is what we would do if range for _12 was say [1, 0x7fff]. And for h, the point was that if only constants are assigned to the variable in a loop, then no matter how many iterations the loop has, the resulting value will only be one of the constants (thus smallest range covering those). Or in this particular case, as the h = 1 assignments is only in endless loop, we could have computed just [0, 0] (but that is probably too rare to care about).
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 --- Comment #25 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Tue Apr 28 08:10:44 2015 New Revision: 222512 URL: https://gcc.gnu.org/viewcvs?rev=222512root=gccview=rev Log: 2015-04-28 Thomas Preud'homme thomas.preudho...@arm.com gcc/ PR target/63503 * config.gcc: Add cortex-a57-fma-steering.o to extra_objs for aarch64-*-*. * config/aarch64/t-aarch64: Add a rule for cortex-a57-fma-steering.o. * config/aarch64/aarch64.h (AARCH64_FL_USE_FMA_STEERING_PASS): Define. (AARCH64_TUNE_FMA_STEERING): Likewise. * config/aarch64/aarch64-cores.def: Set AARCH64_FL_USE_FMA_STEERING_PASS for cores with dynamic steering of FMUL/FMADD instructions. * config/aarch64/aarch64.c (aarch64_register_fma_steering): Declare. (aarch64_override_options): Include cortex-a57-fma-steering.h. Call aarch64_register_fma_steering () if AARCH64_TUNE_FMA_STEERING is true. * config/aarch64/cortex-a57-fma-steering.h: New file. * config/aarch64/cortex-a57-fma-steering.c: Likewise. Added: trunk/gcc/config/aarch64/cortex-a57-fma-steering.c trunk/gcc/config/aarch64/cortex-a57-fma-steering.h Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/aarch64/aarch64-cores.def trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.h trunk/gcc/config/aarch64/t-aarch64
[Bug other/65911] New: [6 Regression] r222508 breaks clang-tblgen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65911 Bug ID: 65911 Summary: [6 Regression] r222508 breaks clang-tblgen Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: tbsaunde at gcc dot gnu.org Target Milestone: --- Starting with r222508 LLVM doesn't build anymore on ppc64le: trippels@gcc2-power8 llvm_build % ./bin/clang-tblgen -gen-clang-attr-impl -I /home/trippels/llvm/tools/clang/include/clang/AST/../../ -I /home/trippels/llvm/tools/clang/include/clang/AST -I /home/trippels/llvm/lib/Target -I /home/trippels/llvm/include /home/trippels/llvm/tools/clang/include/clang/AST/../Basic/Attr.td -o /home/trippels/llvm_build/tools/clang/include/clang/AST/AttrImpl.inc.tmp Program received signal SIGSEGV, Segmentation fault. 0x3fffb79d1ee4 in __strcmp_power7 () from /lib64/libc.so.6 (gdb) bt #0 0x3fffb79d1ee4 in __strcmp_power7 () from /lib64/libc.so.6 #1 0x1005c504 in llvm::cl::generic_parser_base::findOption(char const*) () #2 0x10004f9c in _GLOBAL__sub_I_TableGen.cpp ()
[Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
I meant in the first loop.
But we handle:
int b, c, e;
long
foo (int x, int y)
{
long h = 0;
for (b = 0; b x; b++)
for (c = 0; c y; c++)
if (e)
h = 1;
return h + 4;
}
correctly, it is only as soon as one of those loops turns into endless loop:
int b, c, e;
long
foo (int x, int y)
{
long h = 0;
for (b = 0; b x; b++)
for (c = 0; c y;)
if (e)
h = 1;
return h + 4;
}
that we lose track. But, if it is only for endless loops, probably nothing to
worry about, the finite loops are much more important.
[Bug libstdc++/65913] Linking failure without -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913 --- Comment #3 from yan12125 at gmail dot com --- Sorry, but I don't quite understand. Does that mean for all the future versions (5.2, 6.0, etc.) -latomic flag is necessary if atomicT::is_lock_free() is used in my program?
[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65910 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-apple-darwin14 |x86_64-apple-darwin14, ||powerpc-ibm-aix* Status|NEW |RESOLVED CC||dje at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from David Edelsohn dje at gcc dot gnu.org --- Patch committed.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #20 from Andreas Schwab sch...@linux-m68k.org --- I don't think this has anything to do with the timezone of the commenter. For example the mail for comment #19 has the date Tue, 28 Apr 2015 16:28:19 + (which is correct), but comment #18 was sent with the date Tue, 28 Apr 2015 10:44:58 + (which is 5:30(!) hours off). Both mails were sent immediately after the comment was entered, and I assume that both were entered from the same local timezone.
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- Fixed in glibc (commit 7d0b2575416aec2717e8665287d0ab77826a0ade). I'd advise merging to trunk GCC libquadmath all relevant glibc changes since the last merges in 2012, rather than cherry-picking just this fix (although if you wish to fix things on release branches, cherry-picking just the critical fixes would be appropriate there).
[Bug c++/65919] New: Regression - GCC 5.1 with options -g -std=c++14 fails to compile multiple lambdas used as default function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65919
Bug ID: 65919
Summary: Regression - GCC 5.1 with options -g -std=c++14
fails to compile multiple lambdas used as default
function parameters
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drew.dormann at gmail dot com
Target Milestone: ---
The following program compiles with GCC 4.9, but will not compile using GCC 5.1
Command:
g++ -std=c++14 -g TEST.cpp
Source:
#include functional
struct TestClass
{
static void do_things( std::functionvoid() first = []{},
std::functionvoid() second = []{} );
};
int main()
{
TestClass::do_things();
}
Output:
TEST.cpp:12:1: error: ‘static void
std::_Function_base::_Base_manager_Functor::_M_init_functor(std::_Any_data,
_Functor, std::false_type) [with _Functor = TestClass::lambda();
std::false_type = std::integral_constantbool, false]’ conflicts with a
previous declaration
}
^
In file included from TEST.cpp:1:0:
/usr/include/c++/5/functional:1786:2: note: previous declaration ‘static void
std::_Function_base::_Base_manager_Functor::_M_init_functor(std::_Any_data,
_Functor, std::false_type) [with _Functor = TestClass::lambda();
std::false_type = std::integral_constantbool, false]’
_M_init_functor(_Any_data __functor, _Functor __f, false_type)
^
/usr/include/c++/5/functional:1786:2: note: a later -fabi-version= (or =0)
avoids this error with a change in mangling
TEST.cpp:12:1: error: ‘static void
std::_Function_base::_Base_manager_Functor::_M_destroy(std::_Any_data,
std::false_type) [with _Functor = TestClass::lambda(); std::false_type =
std::integral_constantbool, false]’ conflicts with a previous declaration
}
^
In file included from TEST.cpp:1:0:
/usr/include/c++/5/functional:1724:2: note: previous declaration ‘static void
std::_Function_base::_Base_manager_Functor::_M_destroy(std::_Any_data,
std::false_type) [with _Functor = TestClass::lambda(); std::false_type =
std::integral_constantbool, false]’
_M_destroy(_Any_data __victim, false_type)
^
/usr/include/c++/5/functional:1724:2: note: a later -fabi-version= (or =0)
avoids this error with a change in mangling
TEST.cpp:12:1: error: ‘static void
std::_Function_base::_Base_manager_Functor::_M_clone(std::_Any_data, const
std::_Any_data, std::false_type) [with _Functor = TestClass::lambda();
std::false_type = std::integral_constantbool, false]’ conflicts with a
previous declaration
}
^
In file included from TEST.cpp:1:0:
/usr/include/c++/5/functional:1708:2: note: previous declaration ‘static void
std::_Function_base::_Base_manager_Functor::_M_clone(std::_Any_data, const
std::_Any_data, std::false_type) [with _Functor = TestClass::lambda();
std::false_type = std::integral_constantbool, false]’
_M_clone(_Any_data __dest, const _Any_data __source, false_type)
^
/usr/include/c++/5/functional:1708:2: note: a later -fabi-version= (or =0)
avoids this error with a change in mangling
Version:
g++ -v
Using built-in specs.
COLLECT_GCC=g++-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.1.0-0ubuntu11~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.1.0 (Ubuntu 5.1.0-0ubuntu11~14.04.1)
Observations:
The code will compile if any one of the following changes are made.
- Use g++-4.9
- Compile without the -g option
- Remove either parameter from do_things prototype
- Make do_things prototype a global function instead of a static member
funtion.
- Change the default parameters from a do nothing lambda to a do nothing
function name.
[Bug bootstrap/65910] r222473 breaks x86_64 darwin bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65910 --- Comment #5 from David Edelsohn dje at gcc dot gnu.org --- Author: dje Date: Tue Apr 28 17:16:19 2015 New Revision: 222535 URL: https://gcc.gnu.org/viewcvs?rev=222535root=gccview=rev Log: 2015-04-28 Dominique d'Humieres domi...@lps.ens.fr PR bootstrap/65910 * varasm.c (assemble_end_function): Guard ASM_DECLARE_FUNCTION_SIZE. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c
[Bug libstdc++/65704] Provide portable versions of std::timed_mutex and std::recursive_timed_mutex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65704 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Making this work requires splitting mutex into smaller pieces so that std::timed_mutex can depend on std::condition_variable, which depends on std::mutex. I'll come back to it.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #16 from clyon at gcc dot gnu.org --- (In reply to prathamesh3492 from comment #15) I am not understanding why vfpv3-d16 appears in collect_gcc_options in run_gcc(). Isn't this because you configured GCC --with-fpu=vfpv3-d16?
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Orion Poplawski orion at cora dot nwra.com changed: What|Removed |Added CC||orion at cora dot nwra.com --- Comment #4 from Orion Poplawski orion at cora dot nwra.com --- A recent issue triggered by this: https://bugzilla.redhat.com/show_bug.cgi?id=1127544
[Bug libgcc/65902] GCC-5.1 fails to bootstrap for eCos/arm-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65902 --- Comment #5 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Well, I thought maybe it would not hurt to be more permissive... At least math.h and stdlib.h include cyg/infra/cyg_type.h which contains something like this: #ifndef __cplusplus typedef cyg_halbool bool; # ifndef false # define false 0 # endif # ifndef true # define true (!false) # endif #endif
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #22 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Frédéric Buclin from comment #21) Markus, did you change your timezone preference between comments 18 and 19? If yes, which ones did you select? No. But the question makes no sense, because we're talking about mails that bugzilla automatically sends to the bug mailing lists on every new comment. And I have no control over these.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #23 from Frédéric Buclin LpSolit at netscape dot net --- (In reply to Markus Trippelsdorf from comment #22) No. But the question makes no sense, because we're talking about mails that bugzilla automatically sends to the bug mailing lists on every new comment. And I have no control over these. The question makes total sense as I wanted to excluse a possible interaction between your timezone and the timezone used by Bugzilla to send bugmails. :)
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #21 from Frédéric Buclin LpSolit at netscape dot net --- Markus, did you change your timezone preference between comments 18 and 19? If yes, which ones did you select?
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #24 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Frédéric Buclin from comment #23) (In reply to Markus Trippelsdorf from comment #22) No. But the question makes no sense, because we're talking about mails that bugzilla automatically sends to the bug mailing lists on every new comment. And I have no control over these. The question makes total sense as I wanted to excluse a possible interaction between your timezone and the timezone used by Bugzilla to send bugmails. :) Yeah, sorry. I though you were talking about the Sourceware binutils thread... Here are the headers of comment18 as seen by Gmane: Path: news.gmane.org!not-for-mail From: trippels at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org Newsgroups: gmane.comp.gcc.bugs Subject: [Bug web/6496Here are the headers from comment 18 as seem by gmane: 8] Upgrade GCC Bugzilla to 5.0 Date: Tue, 28 Apr 2015 10:44:58 + Lines: 8 Approved: n...@gmane.org Message-ID: bug-64968-4-ldazd6q...@http.gcc.gnu.org/bugzilla/ References: bug-6496...@http.gcc.gnu.org/bugzilla/ NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1430237721 11722 80.91.229.3 (28 Apr 2015 16:15:21 GMT) X-Complaints-To: use...@ger.gmane.org NNTP-Posting-Date: Tue, 28 Apr 2015 16:15:21 + (UTC) To: gcc-bugs@gcc.gnu.org Original-X-From: gcc-bugs-return-484874-gcgb-bugs-2=m.gmane@gcc.gnu.org Tue Apr 28 18:15:06 2015 Return-path: gcc-bugs-return-484874-gcgb-bugs-2=m.gmane@gcc.gnu.org Envelope-to: gcgb-bug...@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from gcc-bugs-return-484874-gcgb-bugs-2=m.gmane@gcc.gnu.org) id 1Yn8A5-7b-65 for gcgb-bug...@plane.gmane.org; Tue, 28 Apr 2015 18:15:05 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s=default; b=eu7 6Jpj++BEoByfYK1WkSgKWYsgqRvq1b0M/KeNitV7ycQgl4ohrGf06aE1Y/832wKH y/NHq6WvFLytj6vGFKekJhnAeux6xZObH0Enc4lmiW47TFMB7WFG/bhBbk40mNFH jz4WVwxa05bFqSFaPPVrl7Ym8EqWwrBYwxOOEPzM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:in-reply-to:references:content-type :content-transfer-encoding:mime-version; s=default; bh=zsFudk2X+ ANEPRr/cJWaH3SAEF8=; b=jastBc1aGdhM4s2RoZnruY7ZX/FcmBeRB0JEflRMT 68TkmxuDrRvnETjdLSGVZ28Kf18TbSc4ZdK4AYzsQFM5GBTHoRDeehXarAzcwHLq S1VHzdFA3sOjoz89NpDigZ2MYsn0aX3cj9Y4e783mPOPSRRSqsac1nV1hx7khXPE 4A= Original-Received: (qmail 122022 invoked by alias); 28 Apr 2015 16:15:03 - Mailing-List: contact gcc-bugs-h...@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: gcc-bugs.gcc.gnu.org List-Unsubscribe: mailto:gcc-bugs-unsubscribe-gcgb-bugs-2=m.gmane@gcc.gnu.org List-Archive: http://gcc.gnu.org/ml/gcc-bugs/ List-Post: mailto:gcc-bugs@gcc.gnu.org List-Help: mailto:gcc-bugs-h...@gcc.gnu.org Original-Sender:
[Bug c++/65882] [5/6 Regression] Internal compiler error: Error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #4 from Mikhail Maltsev maltsevm at gmail dot com --- For the record. Proposed patch (also contains slightly more reduced testcase): https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01558.html
