[Bug target/59400] [SH] gcc.c-torture/compile/pr55921.c fails with -O0 on big endian with FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59400 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Oleg Endo --- It seems the problem disappeared somewhere between r210624 and r216017 even without LRA.
[Bug c++/70972] [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70972 --- Comment #1 from TC --- Originally from http://stackoverflow.com/q/37064993/2756719
[Bug c++/70972] New: [6/7 Regression] Inheriting constructors taking parameters by value should move them, not copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70972
Bug ID: 70972
Summary: [6/7 Regression] Inheriting constructors taking
parameters by value should move them, not copy
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Keywords: rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
The following code, accepted by GCC 5.3, fails to compile in GCC 6.1 and 7:
struct moveonly {
moveonly(moveonly&&) = default;
moveonly() = default;
};
struct A {
A(moveonly) {}
};
struct B : A {
using A::A;
};
B b(moveonly{});
with a bogus error:
+ g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp
main.cpp: In constructor 'B::B(moveonly)':
main.cpp:10:14: error: use of deleted function 'constexpr
moveonly::moveonly(const moveonly&)'
using A::A;
^
main.cpp:1:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is
implicitly declared as deleted because 'moveonly' declares a move constructor
or move assignment operator
struct moveonly {
^~~~
main.cpp: At global scope:
main.cpp:13:15: note: synthesized method 'B::B(moveonly)' first required here
B b(moveonly{});
Per N4140 [class.inhctor]/8, an implicitly defined inheriting constructor
should cast a passed-by-value parameter to an rvalue before forwarding it to
the base class constructor:
> Each expression in the expression-list [of the mem-initializer for the base
> class] is of the form static_cast(p), where p is the name of the
> corresponding constructor parameter and T is the declared type of p.
(The code above remains valid under the new inheriting constructor semantics in
P0136R1.)
However, GCC 6.1 looks for a copy constructor instead, and would call them
instead of move:
struct abort_on_copy{
abort_on_copy(abort_on_copy&&) = default;
abort_on_copy(const abort_on_copy&) { __builtin_abort(); }
abort_on_copy() = default;
};
struct A {
A(abort_on_copy) {}
};
struct B : A {
using A::A;
};
int main() {
B b(abort_on_copy{}); // aborts
}
[Bug bootstrap/70969] power64le ada bootstrap failure: s-unstyp.ads:40:15: violation of No_Elaboration_Code_All at line 42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70969 --- Comment #1 from Andreas Schwab --- r216965 missed system-linux-ppc64.ads when it added pragma No_Elaboration_Code_All.
[Bug target/5360] [SH] Useless address inc-dec sequence for DFmode access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5360
--- Comment #6 from Oleg Endo ---
When compiling the following test with -m2a -mb -O2
double test (void)
{
return 123.123;
}
we get
mova.L2,r0
fmov.s @r0+,fr0
fmov.s @r0,fr1
rts
add #-4,r0
.L3:
.align 2
.L2:
.long 1079953375
.long 996432413
Although the address reg is dead after the last load, the add #-4 insn is not
eliminated. This is probably because the DFmode move patterns are split at a
late stage during compilation. The add #-4 has to be put there initially
because for the register allocator the DFmode constant looks like it doesn't
modify the address register. In some cases this allows optimizations of
consecutive constant loads, as in:
void test (double* out)
{
out[0] = 123.123;
out[1] = 222;
}
mova.L2,r0
fmov.s @r0+,fr2
fmov.s @r0+,fr3
add #4,r4
fmov.s fr3,@r4
fmov.s fr2,@-r4
fmov.s @r0+,fr2
fmov.s @r0,fr3
add #-4,r0
fmov.s fr2,@(8,r4)
fmov.s fr3,@(12,r4)
rts/n
.L3:
.align 2
.L2:
.long 1079953375
.long 996432413
.long 1080803328
.long 0
[Bug c++/70971] New: ICE in parameter pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70971
Bug ID: 70971
Summary: ICE in parameter pack expansion
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This may not be totally minimal, but the following code:
#include
struct A {};
template
struct B : A { };
template struct typelist {};
template struct tag { using type = T; };
template
std::unique_ptr chooseB(typelist )
{
return std::unique_ptr(new B);
}
template
std::unique_ptr chooseB(typelist choices, Idx i, Rest... rest)
{
auto f = [=](auto tag){
return [=]{ return chooseB(choices, rest...); };
};
std::function()> fs[] = {
f(tag{})...
};
return fs[i]();
}
int main() {
auto p = chooseB(typelist{}, 0, 1, 2);
}
on gcc 5.3 with g++ -std=c++1z -O2 -Wall -Wextra -Wconversion -pedantic
-pthread produced (http://coliru.stacked-crooked.com/a/8dfc904ff5476477)
main.cpp: In function 'std::unique_ptr chooseB(typelist, Idx, Rest
...) [with Ts = {}; Cs = {int, double, char}; Idx = int; Rest = {int, int}]':
main.cpp:29:1: error: unrecognizable insn:
}
^
(insn 28 19 29 2 (set (mem/c:SI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -92 [0xffa4])) [65 MEM[(struct __lambda1
*)&fs + 4B]+0 S4 A32])
(reg/v 101 [ rest#0 ])) -1
(nil))
main.cpp:29:1: internal compiler error: in extract_insn, at recog.c:2287
libbacktrace could not find executable to open
With -g instead of -O2 it compiles but segfaults.
On clang it compiles fine.
[Bug tree-optimization/70970] Misaligned SSE with auto-vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70970 --- Comment #2 from Rodrigo --- Just noticed a dumb mistake in the parameter order of memalign (_aligned_malloc is (size, alignment); memalign is (alignment, size)) but the problem persists. Also forgot that I had to use -march=native under 5.3.1 but not 5.2.0. Sorry for the possible confusion this may cause, the computers in which I tested differ a lot. I just hope you can reproduce it without problems.
[Bug tree-optimization/70970] Misaligned SSE with auto-vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70970 Rodrigo changed: What|Removed |Added Attachment #38424|0 |1 is obsolete|| --- Comment #1 from Rodrigo --- Created attachment 38425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38425&action=edit code (fixed)
[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684 --- Comment #18 from Jerry DeLisle --- Author: jvdelisle Date: Fri May 6 01:18:59 2016 New Revision: 235941 URL: https://gcc.gnu.org/viewcvs?rev=235941&root=gcc&view=rev Log: 2016-05-05 Jerry DeLisle Backport from trunk. PR libgfortran/70684 * io/list_read (next_char): Add '\r' to check for end of line. factor. (two places) PR libgfortran/70684 * gfortran.dg/list_read_14.f90: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/list_read_14.f90 Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/libgfortran/ChangeLog branches/gcc-4_9-branch/libgfortran/io/list_read.c
[Bug tree-optimization/70970] New: Misaligned SSE with auto-vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70970
Bug ID: 70970
Summary: Misaligned SSE with auto-vectorization
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rcc.dark at gmail dot com
Target Milestone: ---
Created attachment 38424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38424&action=edit
the code
Sorry if this has been reported before. I have tested it under:
gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
gcc version 5.2.1 20151028 (Debian 5.2.1-23)
gcc version 6.1.0 (GCC) <- Windows
gcc version 5.2.0 (GCC) <- Windows, MinGW-W64
The following code crashes with -std=c++14 -O3:
#include
#include
template
__attribute__ ((noinline))
void symmetric_difference(RI ai, RI af, RI bi)
{
while (ai != af) {
*ai++ ^= *bi++;
}
}
int main( )
{
auto p1 = reinterpret_cast(memalign(4096, 32));
auto p2 = reinterpret_cast(memalign(4096, 32));
// _aligned_malloc under Windows
auto ai = reinterpret_cast(p1 + 1);
auto bi = reinterpret_cast(p2 + 1);
symmetric_difference(ai, ai + 64, bi);
}
It stops crashing with -O2 or if I remove the + 1 to the pointers; GDB tells me
that the problem lies within:
vmovdqa YMMWORD PTR [rbx+rcx*1],ymm0
The register rbx is not aligned and rcx = 0. It seems that it is reading with
vmovdqu but storing with vmovdqa.
[Bug bootstrap/70969] New: power64le ada bootstrap failure: s-unstyp.ads:40:15: violation of No_Elaboration_Code_All at line 42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70969 Bug ID: 70969 Summary: power64le ada bootstrap failure: s-unstyp.ads:40:15: violation of No_Elaboration_Code_All at line 42 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Current trunk (7.0) fails to bootstrap on powerpc64le, due to the following error: /build/gcc-trunk-bootstrap/./gcc/xgcc -B/build/gcc-trunk-bootstrap/./gcc/ -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem /usr/local/powerpc64le-unknown-linux-gnu/include -isystem /usr/local/powerpc64le-unknown-linux-gnu/sys-include-c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc s-unstyp.ads -o s-unstyp.o s-unstyp.ads:40:15: violation of No_Elaboration_Code_All at line 42 s-unstyp.ads:40:15: unit "System" does not have No_Elaboration_Code_All make[7]: *** [s-unstyp.o] Error 1 make[7]: Leaving directory `/build/gcc-trunk-bootstrap/gcc/ada/rts'
[Bug middle-end/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795 --- Comment #1 from John David Anglin --- Created attachment 38423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38423&action=edit Preprocessed source /test/gnu/gcc/objdir/./gcc/cc1plus -fpreprocessed interpret.ii -quiet -dumpbase interpret.cc -auxbase-strip .libs/interpret.o -g -O2 -Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -fwrapv -fPIC -o interpret.s r235311 is okay. r235318 is bad.
[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70896 --- Comment #6 from PeteVine --- Building with -mfpu=neon has duly helped. The fpu configure option is probably not relevant here (simply setting the default for emitted code) but rather the CFLAGS used for compiling these intrinsics. (-mfpu=vfpv4)
[Bug other/70968] New: Missed case for -Wmisleading-indentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70968
Bug ID: 70968
Summary: Missed case for -Wmisleading-indentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Compiling the following with current trunk:
===
void g(int);
void f1(int x)
{
if (x) {
g(x--);
} while (x);
}
void f2(int x)
{
if (x)
g(x--);
while (x);
}
void f3(int x)
{
if (x) g(x--); while (x);
}
===
(-Wall -W -O2) only warns for f3. f1 has quite misleading indentation.
A warning for "while (x);" wouldn't hurt either probably, if there is
no whitespace before the semicolon anyway, like in f3.
[Bug target/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873 --- Comment #30 from uros at gcc dot gnu.org --- Author: uros Date: Thu May 5 22:48:29 2016 New Revision: 235936 URL: https://gcc.gnu.org/viewcvs?rev=235936&root=gcc&view=rev Log: PR target/70873 * config/i386/i386-protos.h (ix86_standard_x87sse_constant_load_p): New prototype. * config/i386/i386.c (ix86_standard_x87sse_constant_load_p): New. * config/i386/i386.md (push mem splitter): Use find_constant_src in the splitter condition. (FP load splitter): Use ix86_standard_x87sse_constant_load_p in the splitter condition. (FP float_extend load splitter): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md
[Bug c/70967] New: doc: Please document rotate idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70967 Bug ID: 70967 Summary: doc: Please document rotate idiom Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hpa at zytor dot com Target Milestone: --- The idiom that gcc has recognized since time immemorial (gcc 2-something) to generate a rotate: ((foo >> n) + (foo << (sizeof(foo) * CHAR_BIT - n)) /* | instead of + has been recognized for almost but not quite as long */ ... is undefined behavior under the C standard when n == 0. There is a technically portable idiom (bug 57157) which has been recognized since gcc 4.6.3, but that is not portable to older versions of gcc without generating suboptimal code. It would be great if the gcc manual could be augmented to document this idiom for rotate as a GNU C extension so that people are less concerned about its validity, and compilers that mimic the GNU C dialect (icc, clang, etc.) know to implement it correctly.
[Bug tree-optimization/69848] poor vectorization of a loop from SPEC2006 464.h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69848 --- Comment #6 from Jim Wilson --- Testing the vcond_mask* patch with make check gave 6 regressions for both armhf and aarch64. FAIL: gcc.dg/vect/pr65947-10.c (internal compiler error) FAIL: gcc.dg/vect/pr65947-10.c (test for excess errors) FAIL: gcc.dg/vect/pr65947-10.c scan-tree-dump-times vect "LOOP VECTORIZED" 2 FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects (test for excess errors) FAIL: gcc.dg/vect/pr65947-10.c -flto -ffat-lto-objects scan-tree-dump-times vec t "LOOP VECTORIZED" 2 The problem here looks like a flaw in the vcond* patterns. They support int and fp compare operands, but only int selection operands. E.g. for (A op B ? X : Y) A and B can be either int or fp, but X and Y can only be int. Adding the vcond_mask* patterns apparently causes gcc to call vcond* in ways it didn't before, and that exposes the problem. The x86 port is the only port with vcond and vcond_mask patterns, and it supports all four combinations if int/fp compare/select operands, so it appears that aarch64 should also. I will need time to figure out how to fix the vcond* problems before I can formally submit the vcond_mask* patch.
[Bug rtl-optimization/70961] Regrename ignores preferred_rename_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70961
--- Comment #2 from Eric Botcazou ---
> The super_class has nothing to do with the class that is searched for
> renaming registers though, it's just the info passed to the back-end to
> compute this class. For example, on the ARM, the preferred_class will be
> LO_REGS for any chain of GENERAL_REGS.
As a matter of fact, that might not be true, something like
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 235858)
+++ config/arm/arm.c(working copy)
@@ -27721,9 +27721,9 @@ static reg_class_t
arm_preferred_rename_class (reg_class_t rclass)
{
/* Thumb-2 instructions using LO_REGS may be smaller than instructions
- using GENERIC_REGS. During register rename pass, we prefer LO_REGS,
+ using GENERAL_REGS. During register rename pass, we prefer LO_REGS,
and code size can be reduced. */
- if (TARGET_THUMB2 && rclass == GENERAL_REGS)
+ if (TARGET_THUMB2 && reg_class_subset_p (rclass, GENERAL_REGS))
return LO_REGS;
else
return NO_REGS;
could be needed.
[Bug libstdc++/70966] New: new_delete_resource() has deinit lifetime issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70966 Bug ID: 70966 Summary: new_delete_resource() has deinit lifetime issues. Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at efcs dot ca Target Milestone: --- Created attachment 38422 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38422&action=edit example.cpp The value returned from 'new_delete_resource()' should be usable at all stages of program startup and termination. In the current implementation the static deinitialization order fiasco can occur when a static object 'obj' is constructed before the first call to 'new_delete_resource()' and 'obj' references 'new_delete_resource()' in its destructor.
[Bug rtl-optimization/70961] Regrename ignores preferred_rename_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70961 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-05 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > When deciding which register to use regrename.c calls the target function > preferred_rename_class. However in pass 2 in find_rename_reg it then just > ignores this preference. This results in significantly increased codesize on > targets which prefer a subset of allocatable registers in order to use > smaller instructions. Pass #2 ignores it since the preference simply couldn't be honored. > Also the computed super_class appears to be the union of all uses and defs > instead of the intersection. This should be the intersection as that is the > set of registers that all uses and defs support. The super_class has nothing to do with the class that is searched for renaming registers though, it's just the info passed to the back-end to compute this class. For example, on the ARM, the preferred_class will be LO_REGS for any chain of GENERAL_REGS. > If the preferred class doesn't result in a valid rename then it could search > a wider class, but then it would need to check that the size of the newly > selected patterns does not increase. The size is an arbitrary criterion, this could also be the latency, etc.
[Bug sanitizer/70875] ICE in get_ubsan_type_info_for_type with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70875 --- Comment #3 from Jakub Jelinek --- tree_to_uhwi already contains the tree_fits_uhwi_p assert, so there is no reason to duplicate that.
[Bug sanitizer/70875] ICE in get_ubsan_type_info_for_type with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70875
--- Comment #2 from Marek Polacek ---
Seems like an overzealous assert:
diff --git a/gcc/ubsan.c b/gcc/ubsan.c
index 802341e..080f798 100644
--- a/gcc/ubsan.c
+++ b/gcc/ubsan.c
@@ -302,11 +302,14 @@ ubsan_source_location (location_t loc)
static unsigned short
get_ubsan_type_info_for_type (tree type)
{
- gcc_assert (TYPE_SIZE (type) && tree_fits_uhwi_p (TYPE_SIZE (type)));
if (TREE_CODE (type) == REAL_TYPE)
-return tree_to_uhwi (TYPE_SIZE (type));
+{
+ gcc_assert (TYPE_SIZE (type) && tree_fits_uhwi_p (TYPE_SIZE (type)));
+ return tree_to_uhwi (TYPE_SIZE (type));
+}
else if (INTEGRAL_TYPE_P (type))
{
+ gcc_assert (TYPE_SIZE (type) && tree_fits_uhwi_p (TYPE_SIZE (type)));
int prec = exact_log2 (tree_to_uhwi (TYPE_SIZE (type)));
gcc_assert (prec != -1);
return (prec << 1) | !TYPE_UNSIGNED (type);
[Bug middle-end/32003] Undocumened -fdump-tree options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003 --- Comment #4 from Martin Sebor --- With most of the documentation for each option consisting of "the file name is made by appending .xxx to the source file name" I agree that in its current form and state of completion the documentation isn't very useful. I also suspect that providing descriptions for the currently undocumented options and saying much more than what's in the boilerplate blurb above is unlikely. I like the idea of providing a generic description instead, as long is it makes it easy to derive the option names. I had to figure out by trial and error that the name of the option controlling the Object Size Checking dumps is -fdump-tree-objsz (by using -fdump-tree-all, looking at the suffix of the two dump files, and appending it to -fdump-tree-). But after some experimenting and poking around in the manual I realize there's a better way to do it: 1) Run GCC with -fdump-passes and look for the pass code (e.g., objsz for Object Size Checking). 2) Append the pass code to the -fdump-tree- (or -fdump-rtl-) option to enable the dump. 3) Use the pass code to find the name of the dump file created by GCC for the pass (unless overridden). So maybe this would be sufficient documentation for all the options. The one thing missing is a description of what each of those passes actually does. For some it's fairly obvious but for others not so much. Maybe a brief description could be added to GCC's -fdump-passes output to help figure that out (e.g., under -fdump-passes=verbose if we want to keep the current output unchanged). How does this sound?
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
--- Comment #6 from zenith432 at users dot sourceforge.net ---
(In reply to H.J. Lu from comment #5)
> This may be related to PR 50818.
PR 50818 has morphed into a feature request that the canonical
__builtin_va_{list,start,end,copy} builtins behave according to the ABI of the
function they're in. Today they behave according to the '-mabi=' setting on
the command line.
This is bug report that the specialized __builtin_ms_va_{list,start,end,copy}
builtins have stopped working when -flto is used. They worked until gcc 5.3,
both with or without -flto. In gcc 6.1 with -flto, the canonical iterator
__builtin_va_arg ignores them and works on a sysv_va_list. To be precise, it's
__builtin_va_arg in the context of -flto that's broken, not the specialized
builtins. __builtin_va_arg has always been a polymorphic builtin that changes
its behavior based on the type of va_list it's given as an argument. Without
this polymorphic behavior, there's no way to iterate over an ms_va_list.
[Bug c++/70965] ice in useless_type_conversion_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70965 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-05 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/70965] New: ice in useless_type_conversion_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70965 Bug ID: 70965 Summary: ice in useless_type_conversion_p Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 38421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38421&action=edit gzipped C++ source code The attached C++ code, when compiled by gcc trunk dated 20160504, does this: /home/dcb/rpmbuild/BUILD/libkolabxml-1.0.3/src/kolabformat.cpp:291:1: internal compiler error: Segmentation fault } ^ 0xe5113f crash_signal ../../src/trunk/gcc/toplev.c:333 0xb510c0 useless_type_conversion_p(tree_node*, tree_node*) ../../src/trunk/gcc/gimple-expr.c:67 0xf419d0 callsite_arguments_match_p ../../src/trunk/gcc/tree-sra.c:1371 0xf419d0 some_callers_have_mismatched_arguments_p ../../src/trunk/gcc/tree-sra.c:5063 Flag -O2 required.
[Bug middle-end/32003] Undocumened -fdump-tree options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #3 from Marek Polacek ---
I don't see much value in documenting those. It seems to me that we should
simply document that the format is -fdump-{tree,ipa,rtl}-[-].
[Bug middle-end/32003] Undocumened -fdump-tree options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32003 Martin Sebor changed: What|Removed |Added Last reconfirmed|2012-01-28 00:00:00 |2016-5-5 CC||msebor at gcc dot gnu.org Known to fail||4.3.0, 4.5.3, 4.8.3, 4.9.3, ||5.3.0, 6.1.0 --- Comment #2 from Martin Sebor --- The -fdump-tree-objsz is also undocumented. I tried to get a comprehensive list of all undocumented tree dumps. Here's what I came up with for GCC 6.1. It looks like the vast majority of them are, in fact, undocumented. ipa-afdo ipa-build_ssa_passes ipa-cdtor ipa-chkp_cleanup ipa-chkp_ecleanup ipa-chkp_passes ipa-chkp_versioning ipa-comdats ipa-cp ipa-devirt ipa-dispachercalls ipa-emutls ipa-free-inline-summary ipa-hsa ipa-icf ipa-increase_alignment ipa-inline ipa-ipa_oacc ipa-ipa_oacc_kernels ipa-opt_local_passes ipa-profile ipa-profile_estimate ipa-pta1 ipa-pure-const ipa-simdclone ipa-single-use ipa-static-var ipa-targetclone ipa-tmipa ipa-visibility ipa-whole-program statistics aprefetch asan0 asan1 bswap ccp1 cdce cddce1 ch1 chkp chkpopt ch_vect copyprop1 cplxlower0 cplxlower1 crited1 cselim cunroll cunrolli dce1 dom1 dse1 ealias early_optimizations eh ehcleanup1 ehdisp ehopt einline eipa_sra esra fab1 feedback_fnsplit fix_loops fixup_cfg1 fnsplit forwprop1 fre1 graphite graphite0 hsagen ifcombine ifcvt inline_param1 isolate-paths ivcanon ivopts laddress ldist lim1 local-pure-const1 loop loopdone loopinit lower lower_vaarg mergephi1 no_loop nothrow oacc_kernels objsz1 ompexp ompexpssa1 omplower omptargetlink parloops1 pcom phicprop1 phiopt1 phiprop profile_estimate reassoc1 recip release_ssa resx retslot sancov1 sancov_O0 sanopt sccp simduid1 sincos slp1 slsr split-paths stdarg strlen switchconv tailc tailr1 tmedge tmlower tmmark tmmemopt tracer tsan0 tsan1 ubsan uncprop1 uninit1 unswitch veclower veclower21 vrp1 vtable-verify widening_mul
[Bug tree-optimization/57206] Auto-vectorization fails when array index is an unsigned int expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57206 --- Comment #5 from amker at gcc dot gnu.org --- Author: amker Date: Thu May 5 16:20:54 2016 New Revision: 235926 URL: https://gcc.gnu.org/viewcvs?rev=235926&root=gcc&view=rev Log: gcc/testsuite PR tree-optimization/57206 * gcc.dg/vect/pr57206.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr57206.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/70964] [7 Regression] internal compiler error: in single_succ_edge, at basic-block.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70964 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||6.1.0 Target Milestone|--- |7.0 Known to fail||7.0
[Bug tree-optimization/70964] New: [7 Regression] internal compiler error: in single_succ_edge, at basic-block.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70964
Bug ID: 70964
Summary: [7 Regression] internal compiler error: in
single_succ_edge, at basic-block.h:351
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
The testcase:
int a, c, d, e, f;
int b[0];
void
fn1 ()
{
int g;
long h;
for (;;)
{
g = a < 0 ?: g;
long i = d = i < 0 && g < i ?: g + i;
f = 6;
for (; f; f--)
{
h = 6;
for (; h; h--)
{
int j;
long *k;
d || j && (*k = c);
b[f] = e;
}
}
}
}
ICEs on aarch64-none-linux-gnu compiled with -Ofast.
mycrash.c: In function ‘fn1’:
mycrash.c:4:1: internal compiler error: in single_succ_edge, at
basic-block.h:351
fn1 ()
^~~
0x6fdf23 single_succ_edge
$SRC/gcc/basic-block.h:351
0x6fdf23 lv_adjust_loop_entry_edge
$SRC/gcc/cfgloopmanip.c:1658
0x6fdf23 loop_version(loop*, void*, basic_block_def**, unsigned int, unsigned
int, unsigned int, bool)
$SRC/gcc/cfgloopmanip.c:1726
0xb494ff version_loop_for_if_conversion
$SRC/gcc/tree-if-conv.c:2333
0xb494ff tree_if_conversion
$SRC/gcc/tree-if-conv.c:2735
0xb494ff execute
$SRC/gcc/tree-if-conv.c:2829
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Bisection shows this started with r235842.
[Bug target/70963] New: vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70963 Bug ID: 70963 Summary: vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point Product: gcc Version: 5.3.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: markos at freevec dot org Target Milestone: --- Host: powerpc64le-linux-gnu Target: powerpc64le-linux-gnu Build: powerpc64le-linux-gnu Created attachment 38420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38420&action=edit small test program to verify vec_cts/vec_ctf working on doubles I've noticed some tests in Eigen failing for VSX 64-bit doubles code, when the algorithm looked perfectly normal. Further investigation -and comparison with direct output using same inputs from an SSE test program, showed that the conversion to integer yielded 0 results in the case of VSX (vec_cts basically returned 0 vectors). I've written a small test case that verifies this on both big/little endian VSX-capable systems (compiled with -m64 -mvsx). When using the intrinsic the result is wrong, when using the inline asm version, it works as expected. I could not test it in a more recent gcc so it may well be fixed, however it would be great if this would be backported to gcc 5. Some asm output follows from test program (attached): vec_cts: 166c: 60 67 00 f0 xvcvdpsxds vs0,vs12 1670: 50 02 00 f0 xxswapd vs0,vs0 asm: 1674: 51 02 00 f0 xxswapd vs32,vs0 1678: 60 07 00 f0 xvcvdpsxds vs0,vs0 167c: 56 02 00 f0 xxswapd vs0,vs32 vec_ctf: 16f8: 50 02 00 f0 xxswapd vs0,vs0 16fc: e0 07 00 f0 xvcvsxddp vs0,vs0 1700: 50 02 00 f0 xxswapd vs0,vs0 asm: 16f8: 51 02 00 f0 xxswapd vs32,vs0 16fc: e0 07 00 f0 xvcvsxddp vs0,vs0 1700: 56 02 00 f0 xxswapd vs0,vs32
[Bug c++/16106] Poor error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16106 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||4.8.5, 4.9.3, 5.3.0, 6.1.0 Resolution|--- |FIXED Known to fail||4.5.3 --- Comment #3 from Martin Sebor --- Thank you for the update. Resolving as Fixed.
[Bug tree-optimization/70956] ICE in build_cross_bb_scalars_def, at graphite-scop-detection.c:1725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956 --- Comment #2 from Sebastian Pop --- The change looks good to me.
[Bug tree-optimization/68105] optimizing repeated floating point addition to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68105 --- Comment #3 from Marc Glisse --- (In reply to zboson from comment #0) > In addition, the following equations are always true even without > associative math. > > 2*a = a + a > 3*a = a + a + a > 4*a = a + a + a + a > 5*a = a + a + a + a + a > > It turns out that GCC does simplify a + a + a + a to 4*a but only with > associative math enabled e.g. with -Ofast when it could do it with -O3. This "always true" needs some qualification. It is wrong with -frounding-math, where you have to stop at 3 IIRC. (In reply to kugan from comment #2) > Looks like a duplicate of PR63586. I am not convinced this is completely a dup. The patch https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00368.html would probably close PR63586, but not this one since all of the testcases about float in that patch use -ffast-math.
[Bug c++/70962] optimization not working in Red Hat 5.7 after glibc patching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70962 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- Not a gcc issue. Please report this to redhat directly.
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from H.J. Lu --- This may be related to PR 50818.
[Bug c++/70962] New: optimization not working in Red Hat 5.7 after glibc patching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70962
Bug ID: 70962
Summary: optimization not working in Red Hat 5.7 after glibc
patching
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chita40 at gmail dot com
Target Milestone: ---
$ cat tt.c
#include
#include
int main( const int argc, const char * argv[] )
{
std::ifstream in;
in.open( "/dev/null", std::ios::in );
if (in.is_open() ) {
std::cout << "opened" << std::endl;
} else {
std::cout << "failed" << std::endl;
}
return 0;
}
$ g++ tt.c && a.out
opened
$ g++ -O2 tt.c && a.out
failed
[Bug rtl-optimization/70961] New: Regrename ignores preferred_rename_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70961 Bug ID: 70961 Summary: Regrename ignores preferred_rename_class Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: wdijkstr at arm dot com Target Milestone: --- When deciding which register to use regrename.c calls the target function preferred_rename_class. However in pass 2 in find_rename_reg it then just ignores this preference. This results in significantly increased codesize on targets which prefer a subset of allocatable registers in order to use smaller instructions. Also the computed super_class appears to be the union of all uses and defs instead of the intersection. This should be the intersection as that is the set of registers that all uses and defs support. If the preferred class doesn't result in a valid rename then it could search a wider class, but then it would need to check that the size of the newly selected patterns does not increase.
[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70896 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #5 from Ramana Radhakrishnan --- (In reply to PeteVine from comment #4) > Until it failed again during the fortran part: > > ../../../libgfortran/io/transfer.c: In function ‘bswap_array’: > ../../../libgfortran/io/transfer.c:915:25: fatal error: You must enable NEON > instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics. > ((uint16_t*)dest)[i] = __builtin_bswap16 (((uint16_t*)src)[i]); > ^~~ > compilation terminated. > make[3]: *** [transfer.lo] Error 1 > > but that looks like user error. It would be nice if `configure` could abort > or at least warn on not finding `-mfpu=neon` among CFLAGS if fortran was > enabled. > Strange - that shouldn't be happening and certainly looks like a bug - there are a number of folks who bootstrap in Thumb mode and --with-fpu=vfpv3-d16 which is essentially the same as vfpv3 but with only 16 D registers. I'm not sure what's going on here.
[Bug tree-optimization/68105] optimizing repeated floating point addition to multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68105 kugan at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kugan at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from kugan at gcc dot gnu.org --- Looks like a duplicate of PR63586. *** This bug has been marked as a duplicate of bug 63586 ***
[Bug tree-optimization/63586] x+x+x+x -> 4*x in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63586 kugan at gcc dot gnu.org changed: What|Removed |Added CC||zboson at zboson dot net --- Comment #7 from kugan at gcc dot gnu.org --- *** Bug 68105 has been marked as a duplicate of this bug. ***
[Bug target/70873] [7 Regressio] 20% performance regression at 482.sphinx3 after r235442 with -O2 -m32 on Haswell.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70873 --- Comment #29 from Uroš Bizjak --- Created attachment 38419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38419&action=edit Patch to fix problematic splitters I'm testing the attached patch that introduces ix86_standard_x87sse_constant_load_p function, and uses it to limit problematic splitters only to cases, where we can actually transform the insn to a constant load.
[Bug other/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 blastrock at free dot fr changed: What|Removed |Added Attachment #38165|0 |1 is obsolete|| Attachment #38166|0 |1 is obsolete|| --- Comment #3 from blastrock at free dot fr --- Created attachment 38418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38418&action=edit Very small test case I investigated this bug a little more and managed to produce a very small test case. Compile this file with g++ 5.3.1 and clang 3.8 and you will get these two symbols: _Z4moveIRZ5awaitIRiEDaOT_EUlRKS3_E_ES4_S4_ from clang _Z4moveIRZ5awaitIRiEDaOT_EUlRKS2_E_ES3_S3_ from gcc When trying c++filt on the one got from gcc, it will just fail demangling it and print it raw. But when we do it with the one produced by clang, we get a crash. The only difference I see there is the substitutions which are shifted by one on the clang version (I have no idea which compiler is right though). I enabled the debug stuff from the demangle binary in libiberty and got this (I added the addresses of the nodes for debugging): 0x7fffd620: typed name 0x7fffd5d8: template 0x7fffd410: name 'move' 0x7fffd5c0: template argument list 0x7fffd5a8: reference 0x7fffd590: local name 0x7fffd518: typed name 0x7fffd488: template 0x7fffd428: name 'await' 0x7fffd470: template argument list 0x7fffd458: reference 0x7fffd440: builtin type int 0x7fffd500: function type 0x7fffd4a0: name 'auto' 0x7fffd4e8: argument list 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 0x7fffd578: lambda 0 0x7fffd560: argument list 0x7fffd548: reference 0x7fffd530: const 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 0x7fffd608: function type 0x7fffd530: const 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 0x7fffd5f0: argument list 0x7fffd530: const 0x7fffd4d0: rvalue reference 0x7fffd4b8: template parameter 0 What I understand is that when libiberty goes down the first branch, the "template parameter 0" references this same branch and so we get infinite recursion. I guess we can at least prevent the crash if we keep in the state a variable saying which template parameter we are referencing so that we don't go down the same path infinitely. My (de)mangling skills are still very low and I don't think I can solve this one alone. Any help is appreciated.
[Bug middle-end/70960] [7 Regression] ICE: tree check: expected ssa_name, have integer_cst in ifcvt_walk_pattern_tree, at tree-if-conv.c:2465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70960 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-05 Known to work||6.1.0 Summary|[7.0 Regression] ICE: tree |[7 Regression] ICE: tree |check: expected ssa_name, |check: expected ssa_name, |have integer_cst in |have integer_cst in |ifcvt_walk_pattern_tree, at |ifcvt_walk_pattern_tree, at |tree-if-conv.c:2465 |tree-if-conv.c:2465 Ever confirmed|0 |1 Known to fail||7.0 --- Comment #1 from Dominique d'Humieres --- The change occurred between revisions r235803 (OK) and r235816 (ICE).
[Bug middle-end/70960] New: [7.0 Regression] ICE: tree check: expected ssa_name, have integer_cst in ifcvt_walk_pattern_tree, at tree-if-conv.c:2465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70960 Bug ID: 70960 Summary: [7.0 Regression] ICE: tree check: expected ssa_name, have integer_cst in ifcvt_walk_pattern_tree, at tree-if-conv.c:2465 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- recent trunk regression: > cat bug.f90 SUBROUTINE calbrec(a,ai,error) REAL(KIND=8):: a(3,3), ai(3,3) DO i = 1, 3 il = 1 IF (i==1) il = 2 DO j = 1, 3 ai(j,i) = (-1.0_8)**(i+j)*det*(a(il,jl)*a(iu,ju)-a(il,ju)*a(iu,jl)) END DO END DO END SUBROUTINE calbrec > gfortran -c -fprofile-generate -O3 bug.f90 bug.f90:1:0: SUBROUTINE calbrec(a,ai,error) internal compiler error: tree check: expected ssa_name, have integer_cst in ifcvt_walk_pattern_tree, at tree-if-conv.c:2465 0xe42ad4 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9753 0xc095d6 tree_check ../../gcc/gcc/tree.h:3025 0xc095d6 ifcvt_walk_pattern_tree ../../gcc/gcc/tree-if-conv.c:2465 0xc094e0 ifcvt_walk_pattern_tree ../../gcc/gcc/tree-if-conv.c:2491 0xc0edbe ifcvt_repair_bool_pattern ../../gcc/gcc/tree-if-conv.c:2580 0xc0edbe tree_if_conversion ../../gcc/gcc/tree-if-conv.c:2746 0xc0edbe execute ../../gcc/gcc/tree-if-conv.c:2829 0xc0edbe execute ../../gcc/gcc/tree-if-conv.c:2808 Please submit a full bug report, > gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data/vjoost/gnu/gcc_trunk/install/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-lto --disable-bootstrap Thread model: posix gcc version 7.0.0 20160505 (experimental) [trunk revision 235918] (GCC)
[Bug c++/70810] std::function template variadic template arguments do not unpack in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70810
--- Comment #5 from Jonathan Wakely ---
Here is a simplified version of your code which gives an error using GCC, Clang
and Intel icc:
template
T declval();
template
struct function {
template()(declval()...))>
function(F) { }
void operator()(T...) const { }
};
template
struct Invoker {
void invoke(function f, Ts ... args) {
f(args ...);
}
};
template
void invoke(function f, Ts ... args) {
f(args ...);
}
struct string {
string(const char*) { }
};
void foo(string, int) {
}
int main() {
Invoker invoker;
invoker.invoke(foo, "a", 1); // ok
invoke(foo, "a", 1); // fail
}
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-05 Component|target |lto Known to work||5.3.0 Summary|regression in code |[6/7 Regression] Wrong code |generation for |generation for |__builtin_ms_va_list in GCC |__builtin_ms_va_list with |6.1 |-flto Ever confirmed|0 |1 Known to fail||6.1.0, 7.0 --- Comment #4 from Dominique d'Humieres --- Confirmed.
[Bug c++/70810] std::function template variadic template arguments do not unpack in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70810 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- The compiler doesn't have to deduce the parameter pack Ts... in that example, because it is provided explicitly here: Invoker invoker; and so the compiler knows the exact type of std::function here: invoker.invoke(foo, "a", 1); // ok without needing to deduce anything. If Visual Studio compiles it then that seems like a bug in VC++ to me.
[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-05 CC||tkoenig at gcc dot gnu.org Known to work||5.3.0 Summary|Invalid type determination |[6/7 Regression] Invalid |due to expression in a type |type determination due to |declaration statement |expression in a type ||declaration statement Ever confirmed|0 |1 Known to fail||6.1.0, 7.0 Severity|major |normal --- Comment #2 from Dominique d'Humieres --- This is a regression due to r224190.
[Bug c/70954] -Wmisleading-indentation false positive on GNU "ed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70954 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-05 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 zenith432 at users dot sourceforge.net changed: What|Removed |Added Component|c |target --- Comment #3 from zenith432 at users dot sourceforge.net --- This only happens when compiling with -flto. Attached is a standalone sample (va_main.c + va_test.c) gcc -v COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.1.1 20160427 (Red Hat 6.1.1-1) (GCC) gcc -o prog va_main.c va_test.c ./prog sum == 15 gcc -o prog_flto -flto va_main.c va_test.c ./prog_flto Segmentation fault (core dumped)
[Bug c/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #2 from zenith432 at users dot sourceforge.net --- Created attachment 38417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38417&action=edit va_test.c
[Bug c/70955] regression in code generation for __builtin_ms_va_list in GCC 6.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #1 from zenith432 at users dot sourceforge.net --- Created attachment 38416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38416&action=edit va_main.c
[Bug libstdc++/53984] iostream operation throwing exception when exceptions not enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53984 --- Comment #5 from Roger Orr --- Still fails with gcc 6.1 Are there any plans on how (and when) to fix this, fairly serious, fault?
[Bug tree-optimization/70956] ICE in build_cross_bb_scalars_def, at graphite-scop-detection.c:1725
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956
vries at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #1 from vries at gcc dot gnu.org ---
Consider graphite_find_cross_bb_scalar_vars:
...
static void
graphite_find_cross_bb_scalar_vars (scop_p scop, gimple *stmt,
vec *reads, vec *writes)
{
tree def;
if (gimple_code (stmt) == GIMPLE_ASSIGN)
def = gimple_assign_lhs (stmt);
else if (gimple_code (stmt) == GIMPLE_CALL)
def = gimple_call_lhs (stmt);
else if (gimple_code (stmt) == GIMPLE_PHI)
def = gimple_phi_result (stmt);
else
return;
build_cross_bb_scalars_def (scop, def, gimple_bb (stmt), writes);
...
...
We arrive at graphite_find_cross_bb_scalar_vars with:
...
(gdb) call debug_gimple_stmt (stmt)
# VUSE <.MEM_10(D)>
f2 (_1);
...
The call is resultless, so def becomes NULL_TREE.
This tentative patch handles NULL_TREE def in build_cross_bb_scalars_def, and
fixes the assert:
...
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
index 7615842..dd50a1e 100644
--- a/gcc/graphite-scop-detection.c
+++ b/gcc/graphite-scop-detection.c
@@ -1722,8 +1722,7 @@ static void
build_cross_bb_scalars_def (scop_p scop, tree def, basic_block def_bb,
vec *writes)
{
- gcc_assert (def);
- if (!is_gimple_reg (def))
+ if (!def || !is_gimple_reg (def))
return;
/* Do not gather scalar variables that can be analyzed by SCEV as they can
be
...
