[Bug other/53313] Add warning levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||easyhack --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- It doesn't make sense to really enable every -Wx option, some of them are too specialized (-Wdouble-promotion, -Wtraditional, -Wlarger-than=, -Wc++-compat, etc.) However, if someone goes through the trouble of compiling a list of potential candidates, it should be trivial to implement using EnabledBy() in common.opt, c.opt, etc. Now I think the original proposal of having warnings levels is not what GCC wants. In fact, we now have -Ofast, -Os, and -Og and the consensus seems to be that we do not want to have -O4. According to https://gcc.gnu.org/wiki/DiagnosticsGuidelines quote * enabled by default if it has (almost) no false positives (e.g., -Woverflow); * added to -Wall if it is generally useful with low number of false positives that are easy to work-around; * added to -Wextra if it has quite a lot of false positives but they are still easy to work-around; Warning options should move up in this list when bugfixes reduce the number of false positives. These cases are not meant to be exhaustive: some options should never be enabled by other option if the warning is too specific (-Wdouble-promotion); other options are already controlled by options such as -Wpedantic and -Wformat and do not need to move up in this list (but they might if deemed useful). /quote We could add: * always added to -Weverything unless the warning was never meant to be generally useful even if it were perfect (-Wdouble-promotion, -Wtraditional, -Wlarger-than=, -Wc++-compat, etc.).
[Bug target/65296] [avr] fix various issues with specs file generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65296 --- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Wed Apr 22 16:14:50 2015 New Revision: 222333 URL: https://gcc.gnu.org/viewcvs?rev=222333root=gccview=rev Log: Backport from trunk r222179. 2015-04-17 Sivanupandi Pitchumani pitchumani.sivanupa...@atmel.com PR target/65296 * config/avr/gen-avr-mmcu-specs.c (*avrlibc_startfile): Adjust to new AVR-LibC file layout (bug #44574). (*avrlibc_devicelib): Same. * config/avr/avr-mcus.def: Adjust comments. * config/avr/avr.opt (nodevicelib): Adjust help. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/avr/avr-mcus.def branches/gcc-5-branch/gcc/config/avr/avr.opt branches/gcc-5-branch/gcc/config/avr/gen-avr-mmcu-specs.c
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #7 from vries at gcc dot gnu.org --- Hmm, this patch has failures for x86_64: - va_arg (ap, void): gcc.c-torture/compile/pr48767.c - vla: gcc.c-torture/execute/20020412-1.c gcc.dg/compat/struct-by-value-22 gcc.dg/lto/20090706-1 gcc.target/i386/memcpy-strategy-4.c this patch is more conservative: ... diff --git a/gcc/gimplify.c b/gcc/gimplify.c index 7786e16..e23f510 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -9336,7 +9336,12 @@ gimplify_va_arg_internal (tree valist, tree type, location_t loc, else gimplify_expr (valist, pre_p, post_p, is_gimple_min_lval, fb_lvalue); - return targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p); + tree expr = targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p); + gcc_assert (TREE_CODE (expr) == MEM_REF); + if (!is_gimple_mem_ref_addr (TREE_OPERAND (expr, 0))) +gimplify_expr (TREE_OPERAND (expr, 0), pre_p, post_p, + is_gimple_mem_ref_addr, fb_rvalue); + return expr; } /* Gimplify __builtin_va_arg, aka VA_ARG_EXPR, which is not really a ... It allows at least pr48767.c, 20020412-1.c and memcpy-strategy-4.c to pass.
[Bug testsuite/59971] multilib_flags is placed with the wrong order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59971 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Fixed by dejagnu 1.5.3 instead.
[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848 --- Comment #2 from Andrew Sutton andrew.n.sutton at gmail dot com --- Here's the result of the latest commit (r222332) on my system. test.cpp is the program in the bug report. Command being timed: ~/opt/bin/g++ -std=c++1z -c test.cpp User time (seconds): 0.04 System time (seconds): 0.01 Percent of CPU this job got: 91% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.07 ... Maximum resident set size (kbytes): 49344 ... Minor (reclaiming a frame) page faults: 4465
[Bug target/65846] Optimize data access in PIE with copy reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65846 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-22 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01331.html
[Bug target/65836] [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 --- Comment #4 from ktkachov at gcc dot gnu.org --- Bisection confirmed that it's r222173: Author: vries vries@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Apr 17 09:26:59 2015 + Postpone expanding va_arg until pass_stdarg 2015-04-17 Tom de Vries t...@codesourcery.com Michael Matz m...@suse.de I'll try updating my tree to r222318 Author: vries vries@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Apr 22 09:03:01 2015 + Fix va_arg ap_copy nop detection 2015-04-22 Tom de Vries t...@codesourcery.com PR tree-optimization/65823 * gimplify.c (gimplify_modify_expr): Use operand_equal_p to test for equality between ap_copy and ap. and see if that fixes it
[Bug fortran/65841] Seg fault on intrinsic assignment to allocatable derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65841 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I confirm the segfault with my clean trees for all variants (4.8 and 4.9 give an ICE). However I don't see them on my patched trees having Mikael's patch for pr65792 (https://gcc.gnu.org/ml/fortran/2015-04/msg00063.html) and Andre's one for pr59678 (https://gcc.gnu.org/ml/fortran/2015-04/msg00061.html). Note that the last test in comment 1 segfault with only the [fist patch] for pr65792 + the one for pr59678. All the test run without segfault with the cumulated patch for pr61831 and pr65792 (https://gcc.gnu.org/bugzilla/attachment.cgi?id=35352) + the one for pr59678. Note also that repeated assignments is checked by gfortran.dg/alloc_comp_assign_10.f90 (pr39879): u%model = u%design u%model = u%design ! The double assignment was the cause of the ICE
[Bug c++/65845] New: typeid doesn't work consistently on pure virtual classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65845
Bug ID: 65845
Summary: typeid doesn't work consistently on pure virtual
classes
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: laszlo.bodor at citi dot com
#include typeinfo
class Interface {
public:
virtual int size() const = 0;
};
template class T
class Vector {
public:
void resize(unsigned n, T val = T()); //C++03 style resize
// void resize(unsigned n, const T val); //C++11 style resize
private:
T* data;
};
int main()
{
typeid(Interface).name();
typeid(Interface()).name(); //GCC 4.9.2 and VS2013: doesn't compile
typedef Interface* PtrInterf;
PtrInterf p1 = 0;
typeid(PtrInterf).name();
typeid(PtrInterf()).name();
typeid(p1).name();
//typeid(VectorInterface).name(); //GCC 4.9.2 and icc 13.0.1: doesn't
compile
typeid(VectorInterface()).name();
typedef VectorInterface* PtrVecInterf;
PtrVecInterf p2 = 0;
typeid(PtrVecInterf).name(); //GCC 4.9.2: doesn't compile
typeid(PtrVecInterf()).name();
typeid(p2).name(); //GCC 4.9.2: doesn't compile
return 0;
}
Compiler version:
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure --disable-nls --prefix=/home/gcc4.9
--with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran --disable-multilib
--with-system-zlib --enable-checking=release --enable-__cxa_atexit
Thread model: posix
gcc version 4.9.2 (GCC)
and
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-src/configure --disable-nls --prefix=/home/gcc5-trunk
--with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran --disable-multilib
--with-system-zlib --enable-checking=release --enable-__cxa_atexit
Thread model: posix
gcc version 6.0.0 20150421 (experimental) (GCC)
Description:
The above code compiles on GCC 4.7.3, but it doesn't compile on GCC 4.9.2 and
on a recent GCC trunk. Clang 3.7 compiles the code.
The standard doesn't seem to be very clear on this issue but we would prefer if
typeid work as many cases as possible.
[Bug c++/65845] typeid doesn't work consistently on pure virtual classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65845
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Severity|major |normal
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
The expression typeid(Interface()) is the type of a function that returns
Interface, but such a function cannot exist because the type is abstract.
I don't know why typeid(VectorInterface) needs to instantiate the default
argument.
The output from trunk is:
t.cc: In function ‘int main()’:
t.cc:20:20: error: ‘type name’ declared as function returning an abstract class
type
typeid(Interface()).name(); //GCC 4.9.2 and VS2013: doesn't compile
^
t.cc: In instantiation of ‘class VectorInterface’:
t.cc:38:1: required from here
t.cc:11:8: error: cannot allocate an object of abstract type ‘Interface’
void resize(unsigned n, T val = T()); //C++03 style resize
^
t.cc:3:7: note: because the following virtual functions are pure within
‘Interface’:
class Interface {
^
t.cc:5:15: note:virtual int Interface::size() const
virtual int size() const = 0;
^
[Bug tree-optimization/59970] Bogus warnings at low optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970
Mike Crowe mac at mcrowe dot com changed:
What|Removed |Added
CC||mac at mcrowe dot com
--- Comment #3 from Mike Crowe mac at mcrowe dot com ---
Created attachment 35384
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35384action=edit
Preprocessed source for boost::lexical_cast case
I can reproduce the same problem with Debian Jessie's gcc 4.9.2 and a
self-compiled gcc 4.9.1 when compiling:
#include boost/lexical_cast.hpp
int wibble()
{
return boost::lexical_castint(1);
}
Preprocessed source attached (compressed to avoid file size limit.)
$ g++ -Wall -Werror -Og -save-temps test.cpp
test.cpp: In function ‘int wibble()’:
test.cpp:5:40: error: ‘result’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
return boost::lexical_castint(1);
^
cc1plus: all warnings being treated as errors
Oddly the warning is not reported when the function is named main!
[Bug rtl-optimization/64916] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 --- Comment #8 from Jeffrey A. Law law at redhat dot com --- Alex, you're right. It's just an artifact which patch I pulled out of my todo list. Your patches are effectively doing the same thing. If you'd like I can add you to the ChangeLog entry for the fix.
[Bug c++/65848] New: [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848
Bug ID: 65848
Summary: [c++-concepts] High memory usage and compilation times
for subsuming concept chains; regression from r211824
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates high CPU and memory utilization during
compilation when compiled with gcc r38. I have an old gcc build (r211824)
that compiles this test case quickly with low memory usage. Details are below
the test case.
The performance issue depends on use of the type trait templates. Replacing
references to them with 'true' suffices to enable the code to be quickly
compiled (though possibly with still higher resource usage then with an r211824
build, I didn't measure). Likewise, reducing the length of the CNT concept
chain or the number of types for which concepts are asserted has an exponential
effect on resource usage. Increasing the length of the concept chain much
further results in compilations that will not complete successfully on my
modest hardware (Lenovo T420 laptop with 8GB ram).
I attempted to remove the dependency on the type_traits header, but the number
of entities I would have needed to add to the test case below would have made
the test case much longer. Simplifying their implementation to keep the test
case small greatly reduced resource usage. It seems their implementation is
relevant to the issue.
$ cat t.cpp
#include type_traits
templatetypename T
concept bool Destructible() {
return std::is_destructibleT::value;
}
templatetypename T, typename... Args
concept bool Constructible() {
return DestructibleT() std::is_constructibleT, Args...::value;
}
templatetypename T
concept bool Move_constructible() {
return ConstructibleT, T();
}
templatetypename T
concept bool Copy_constructible() {
return Move_constructibleT() ConstructibleT, const T();
}
templatetypename T, typename U
concept bool Assignable() {
return std::is_assignableT, U::value;
}
templatetypename T
concept bool Move_assignable() {
return AssignableT, T();
}
templatetypename T
concept bool Copy_assignable() {
return Move_assignableT() AssignableT, const T();
}
templatetypename T
concept bool Copyable() {
return Copy_constructibleT() Copy_assignableT();
}
templatetypename T
concept bool C1() { return CopyableT(); }
templatetypename T
concept bool C2() { return C1T(); }
templatetypename T
concept bool C3() { return C2T(); }
templatetypename T
concept bool C4() { return C3T(); }
templatetypename T
concept bool C5() { return C4T(); }
templatetypename T
concept bool C6() { return C5T(); }
templatetypename T
concept bool C7() { return C6T(); }
templatetypename T
concept bool C8() { return C7T(); }
templatetypename T
concept bool C9() { return C8T(); }
templatetypename T
concept bool C10() { return C9T(); }
templatetypename T
concept bool C11() { return C10T(); }
struct S1 {};
struct S2 {};
struct S3 {};
struct S4 {};
struct S5 {};
struct S6 {};
static_assert(C11S1(), );
static_assert(C11S2(), );
static_assert(C11S3(), );
static_assert(C11S4(), );
static_assert(C11S5(), );
static_assert(C11S6(), );
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 38
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 36
Last Changed Date: 2015-04-20 09:43:31 -0400 (Mon, 20 Apr 2015)
Timing details for both the r38 gcc build above and an old r211824 based
build follow. The timing data was produced by /usr/bin/time on an Ubuntu 12.04
system. The data below was produced with a hot cache in each case.
# Using gcc r38, compilation time and memory usage is significant:
$ /usr/bin/time -v g++ -c -std=c++1z t.cpp
Command being timed: g++ -c -std=c++1z t.cpp
User time (seconds): 17.73
System time (seconds): 0.88
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:18.67
...
Maximum resident set size (kbytes): 8409216
...
Minor (reclaiming a frame) page faults: 527712
...
# Using an old gcc r211824, compilation completes quickly (note
# that this old build required -std=c++1y to enable support for concepts).
$ /usr/bin/time -v g++ -c -std=c++1y t.cpp
Command being timed: g++ -c -std=c++1y t.cpp
User time (seconds): 0.05
System time (seconds): 0.00
Percent of CPU this job got: 88%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.06
...
Maximum resident set size (kbytes): 63936
...
Minor (reclaiming a frame) page faults: 6107
[Bug rtl-optimization/64916] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 --- Comment #9 from Alex Velenko Alex.Velenko at arm dot com --- Jeff, thank you for noticing this. I don't mind this time, I just hope this would not happen next time.
[Bug rtl-optimization/64905] unsigned short is loaded with 4-byte load (movl)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64905 Ruben Ayrapetyan r.ayrapetyan at samsung dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Ruben Ayrapetyan r.ayrapetyan at samsung dot com --- Verified on version 5.1.0.
[Bug target/65836] [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||tom at codesourcery dot com --- Comment #5 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #4) and see if that fixes it No, that didn't fix it. This is still present as of r222322
[Bug target/61551] [NEON] alter costs to allow use of post-indexed addressing modes for VLD{2..4}/VST{2..4}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61551 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.2 |6.0 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- This really is 6.0 now - I can't see this as being eligible for the 5.x branches.
[Bug fortran/65841] Seg fault on intrinsic assignment to allocatable derived type with allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65841 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-22 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paul Thomas pault at gcc dot gnu.org --- Confirmed type a real, allocatable :: f end type type b type(a), allocatable :: g end type type(b) c,d c%g=a(1.) d=c d%g%f = 2.0 ! This causes the segfault too end However, if I make c and d allocatable type a real, allocatable :: f end type type b type(a), allocatable :: g end type type(b), allocatable :: c, d ! Note allocatable now allocate (c) c%g = a (1.) d = c d = c end ... it does not segfault. Note both must be allocatable for this to work. This should be a clue but I still do not see what is wrong with the code produced for the segfaulting cases. More staring at it tonight! Thanks for the report Paul
[Bug target/65846] New: Optimize data access in PIE with copy reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65846
Bug ID: 65846
Summary: Optimize data access in PIE with copy reloc
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: evstupac at gmail dot com
Target: i386-elf
With linker which supports copy relocation in PIE:
https://sourceware.org/bugzilla/show_bug.cgi?id=18289
For
extern int glob_a;
int foo ()
{
return glob_a;
}
compiler can optimize it from
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
movlglob_a@GOT(%eax), %eax
movl(%eax), %eax
ret
to
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFFSET_TABLE_, %eax
movlglob_a@GOTOFF(%eax), %eax
ret
[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848 --- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com --- This is caused by the use of a concept outside of a requires clause -- it's still a bug though. The TS doesn't actually include wording that would allow this program to be valid. Unfortunately, the first thing people do when they have concepts it to write tests that statically assert them, so I've been extending the proposal to make that valid. The performance regression is related to that. When you call C11S6(), we normalize that expression as a constraint and check it. Unfortunately, that same logic applies for *every single concept check* that appears in an expression formed while normalizing that constraint. Basically, you're invoking a giant recursive yo-yo in order to evaluate the constraint. Like I said... still a bug. I hope to have this resolved in the next half hour.
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #3 from vries at gcc dot gnu.org --- The code snippet: ... case 'f': case 'e': case 'E': case 'g': case 'G': (void) __builtin_va_arg(ap, double); total_width += 307; break; ... translates to: ... L23: VA_ARG (ap, 0B); total_width_70 = total_width_31 + 337; # DEBUG total_width = total_width_70 goto bb 21 (L31); ... at the end of hppa_gimplify_va_arg_expr, the result looks like: ... (gdb) p *pre_p $2 = (gimple_seq) 0x0 (gdb) p *post_p $3 = (gimple_seq) 0x0 (gdb) call debug_generic_expr (t) *(double *) (ap = ap + 4294967288 4294967288B) ... Note that pre_p and post_p are empty, and t contains the side-effect of assigning to ap. Since ifn_va_arg has no lhs, the returned value is not assigned to any var in expand_ifn_va_arg_1, and the side-effect is lost. We need to further gimplify the expression to fix the error. [ I wonder whether that's the responsibility of TARGET_GIMPLIFY_VA_ARG_EXPR. ]
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #8 from dave.anglin at bell dot net --- On 2015-04-22 12:40 PM, vries at gcc dot gnu.org wrote: this patch is more conservative Restarted test with updated patch.
[Bug c++/65850] 5.1 regression [graphite]: isl_constraint.c:625: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65850 --- Comment #1 from Dâniel Fraga fragabr at gmail dot com --- Created attachment 35385 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35385action=edit Unified_cpp_layout_base0.ii I had to bzip2 it because of the size. Sorry.
[Bug tree-optimization/59970] Bogus warnings at low optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970 --- Comment #4 from Mike Crowe mac at mcrowe dot com --- The test case in comment #3 shows the same problem in gcc-5-branch r222333.
[Bug target/65849] New: Add missing tuning knobs to #pragma target/attribute target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65849
Bug ID: 65849
Summary: Add missing tuning knobs to #pragma target/attribute
target support
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
Build: powerpc64-unknown-linux-gnu
Some of the -moption tuning knobs were not allowed for #pragma target ...
and attribute ((target(...))) support. At first glance, we should add support
for -m{,no-}save-toc-indirect, -m{,no-}optimize-swaps,
-m{,no-}upper-regs-{sf,df}.
Options that affect the ABI (like -mpointers-to-nested-functions, -mabi=...,
-mlittle, -m32, etc.) should not be added, but where possible the other options
should be added.
[Bug target/65849] Add missing tuning knobs to #pragma target/attribute target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65849 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-22 Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/65850] New: 5.1 regression [graphite]: isl_constraint.c:625: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65850 Bug ID: 65850 Summary: 5.1 regression [graphite]: isl_constraint.c:625: expecting integer value Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fragabr at gmail dot com I tried to compile Firefox 37.0.2 with gcc 5.1 and I got this compiler error. I attached the .ii file. Using built-in specs. COLLECT_GCC=c++ Target: x86_64-unknown-linux-gnu Configured with: ../gcc-5.1.0/configure --disable-multilib --disable-isl-version-check --enable-cloog-backend=isl --enable-languages=c,c++ Thread model: posix gcc version 5.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'Unified_cpp_layout_base0.o' '-c' '-I' '../../dist/stl_wrappers' '-I' '../../dist/system_wrappers' '-include' '/home/fraga/src/mozilla/config/gcc_hidden.h' '-D' 'OS_POSIX=1' '-D' 'OS_LINUX=1' '-D' 'STATIC_EXPORTABLE_JS_API' '-D' 'MOZILLA_INTERNAL_API' '-D' 'IMPL_LIBXUL' '-D' 'MOZ_GLUE_IN_PROGRAM' '-D' 'AB_CD=en-US' '-D' 'NO_NSPR_10_SUPPORT' '-I' '/home/fraga/src/mozilla/layout/base' '-I' '.' '-I' '/home/fraga/src/firefox/ipc/ipdl/_ipdlheaders' '-I' '/home/fraga/src/mozilla/ipc/chromium/src' '-I' '/home/fraga/src/mozilla/ipc/glue' '-I' '/home/fraga/src/mozilla/layout/base/../forms' '-I' '/home/fraga/src/mozilla/layout/base/../generic' '-I' '/home/fraga/src/mozilla/layout/base/../mathml' '-I' '/home/fraga/src/mozilla/layout/base/../printing' '-I' '/home/fraga/src/mozilla/layout/base/../style' '-I' '/home/fraga/src/mozilla/layout/base/../svg' '-I' '/home/fraga/src/mozilla/layout/base/../tables' '-I' '/home/fraga/src/mozilla/layout/base/../xul' '-I' '/home/fraga/src/mozilla/layout/base/../xul/tree/' '-I' '/home/fraga/src/mozilla/docshell/base' '-I' '/home/fraga/src/mozilla/dom/base' '-I' '/home/fraga/src/mozilla/dom/html' '-I' '/home/fraga/src/mozilla/dom/svg' '-I' '/home/fraga/src/mozilla/dom/xbl' '-I' '/home/fraga/src/mozilla/view' '-I' '../../dist/include' '-I' '/usr/local/include/nspr' '-I' '/usr/include/nss' '-I' '/usr/xorg/include/pixman-1' '-fPIC' '-I' '/usr/X11/include' '-I' '/usr/local/include/nss' '-D' 'MOZILLA_CLIENT' '-include' '../../mozilla-config.h' '-MD' '-MP' '-MF' '.deps/Unified_cpp_layout_base0.o.pp' '-I' '/usr/X11/include' '-I' '/usr/local/include/nss' '-Wall' '-Wempty-body' '-Woverloaded-virtual' '-Wsign-compare' '-Wwrite-strings' '-Wno-invalid-offsetof' '-Wcast-align' '-march=native' '-O3' '-pipe' '-floop-interchange' '-floop-strip-mine' '-floop-block' '-fno-strict-aliasing' '-fno-rtti' '-fno-exceptions' '-fno-math-errno' '-std=gnu++11' '-pthread' '-pipe' '-D' 'NDEBUG' '-D' 'TRIMMED' '-g' '-freorder-blocks' '-Os' '-fomit-frame-pointer' '-I' '/usr/xorg/include/pixman-1' '-I' '/usr/X11/include' '-I' '/usr/local/include' '-I' '/usr/local/include/freetype2' '-I' '/usr/local/include/libpng16' '-I' '/usr/local/include/harfbuzz' '-I' '/usr/xorg/include' '-I' '/usr/local/include/cairo' '-I' '/usr/local/include/glib-2.0' '-I' '/usr/local/lib/glib-2.0/include' '-I' '/usr/xorg/include' '-I' '/usr/xorg/include/pixman-1' '-I' '/usr/X11/include' '-I' '/usr/local/include' '-I' '/usr/local/include/freetype2' '-I' '/usr/local/include/libpng16' '-I' '/usr/local/include/harfbuzz' '-I' '/usr/local/include/cairo' '-I' '/usr/local/include/glib-2.0' '-I' '/usr/local/lib/glib-2.0/include' '-shared-libgcc' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/cc1plus -E -quiet -v -I ../../dist/stl_wrappers -I ../../dist/system_wrappers -I /home/fraga/src/mozilla/layout/base -I . -I /home/fraga/src/firefox/ipc/ipdl/_ipdlheaders -I /home/fraga/src/mozilla/ipc/chromium/src -I /home/fraga/src/mozilla/ipc/glue -I /home/fraga/src/mozilla/layout/base/../forms -I /home/fraga/src/mozilla/layout/base/../generic -I /home/fraga/src/mozilla/layout/base/../mathml -I /home/fraga/src/mozilla/layout/base/../printing -I /home/fraga/src/mozilla/layout/base/../style -I /home/fraga/src/mozilla/layout/base/../svg -I /home/fraga/src/mozilla/layout/base/../tables -I /home/fraga/src/mozilla/layout/base/../xul -I /home/fraga/src/mozilla/layout/base/../xul/tree/ -I /home/fraga/src/mozilla/docshell/base -I /home/fraga/src/mozilla/dom/base -I /home/fraga/src/mozilla/dom/html -I /home/fraga/src/mozilla/dom/svg -I /home/fraga/src/mozilla/dom/xbl -I /home/fraga/src/mozilla/view -I ../../dist/include -I /usr/local/include/nspr -I /usr/include/nss -I /usr/xorg/include/pixman-1 -I /usr/X11/include -I /usr/local/include/nss -I /usr/X11/include -I /usr/local/include/nss -I /usr/xorg/include/pixman-1 -I /usr/X11/include -I /usr/local/include -I /usr/local/include/freetype2 -I /usr/local/include/libpng16 -I /usr/local/include/harfbuzz -I /usr/xorg/include -I /usr/local/include/cairo -I /usr/local/include/glib-2.0 -I /usr/local/lib/glib-2.0/include -I /usr/xorg/include -I /usr/xorg/include/pixman-1 -I /usr/X11/include
[Bug c++/65850] 5.1 regression [graphite]: isl_constraint.c:625: expecting integer value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65850 --- Comment #2 from Dâniel Fraga fragabr at gmail dot com --- Without graphite optimization, it compiles fine.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
Well,
/* Return the ARM builtin for CODE. */
tree
arm_builtin_decl (unsigned code, bool initialize_p ATTRIBUTE_UNUSED)
{
if (code = ARM_BUILTIN_MAX)
return error_mark_node;
return arm_builtin_decls[code];
}
and LTO passes in true for initialize_p ...
Thus it looks like arm is simply missing LTO support for builtins
(eventually a new symptom here because of the way we stream compiler
options now, with target attributes)
Well, we defined TARGET_BUILTIN_DECL a few years back for precisely supporting
LTO streaming of builtins - can you elaborate further what target support is
missing and for quite a while this was working ?
What did we miss when adding that support ?
[Bug rtl-optimization/65067] regression on accessing volatile bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- fixed ?
[Bug rtl-optimization/65067] regression on accessing volatile bit field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65067 --- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Ramana Radhakrishnan from comment #12) fixed ? yes, thanks.
[Bug lto/65778] v8 build fails with assembly error with LTO enabled on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65778 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) Can't you not use just a move instead of a ldr here? basically it is the assembler which creates the constant pool here and that is too far from the where the ldr is located because the function is huge. Indeed the compiler has no role here. It's not like __ARM_NR_cacheflush is going to change is it ? You can write it similar to the libgcc implementation for clear_cache. regards Ramana
[Bug target/48904] x86_64-knetbsd-gnu fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48904 Bernhard Reutner-Fischer aldot at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2013-02-25 00:00:00 |2015-04-22 CC||aldot at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.9.0, 5.0 --- Comment #3 from Bernhard Reutner-Fischer aldot at gcc dot gnu.org --- confirmed. PR target/48904: x86_64-knetbsd-gnu missing defs 2012-09-21 H.J. Lu hongjiu...@intel.com * config.gcc (x86_64-*-knetbsd*-gnu): Add i386/knetbsd-gnu64.h. * config/i386/knetbsd-gnu64.h: New file
[Bug rtl-optimization/65304] [4.9] [ARM] incorrect asm operand has impossible constraints error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65304 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-22 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1
[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to amker from comment #4) Author: amker Date: Wed Apr 22 09:37:52 2015 New Revision: 222319 URL: https://gcc.gnu.org/viewcvs?rev=222319root=gccview=rev Log: Backport from trunk r55 2015-04-21 Bin Cheng bin.ch...@arm.com PR testsuite/65767 * g++.dg/lto/pr65276_0.C: Change namespace std to std2. * g++.dg/lto/pr65276_1.C: Change namespace std to std2. Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/g++.dg/lto/pr65276_0.C branches/gcc-5-branch/gcc/testsuite/g++.dg/lto/pr65276_1.C Fixed.
[Bug target/65711] arm*-linux* link spec passes '-dynamic-linker' even for '-shared'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65711 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Ludovic Courtès from comment #1) Created attachment 35270 [details] Proposed patch Patches on gcc-patches please as per policy.
[Bug target/65326] LRA missing a Thumb optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65326 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-22 CC||ramana at gcc dot gnu.org, ||yvan.roux at linaro dot org Known to work||4.8.0, 4.8.1, 4.8.2, 4.9.0, ||4.9.1, 4.9.2, 4.9.3 Ever confirmed|0 |1 Known to fail||5.0, 6.0
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- fixed on 5.0
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Hi,
I tried to reproduce the error with a reduced test-case:
#include arm_neon.h
float32x2_t a, b, c, e;
int main()
{
e = __builtin_neon_vmls_lanev2sf (a, b, c, 0);
return 0;
}
arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c
arm-linux-gnueabihf-gcc test.o -flto -o test
lto1: fatal error: target specific builtin not available
compilation terminated.
lto-wrapper: fatal error:
/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc
returned 1 exit status
compilation terminated.
However passing -mfpu=neon for linking works:
arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test
I suppose similar thing must be happening during linking
libshared_memory_support.so for chromium build ?
I couldn't see -mfpu=neon in the command line used for linking
libshared_memory_support.so
Thank you,
Prathamesh
[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
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
(In reply to Ramana Radhakrishnan from comment #4)
(In reply to prathamesh3492 from comment #3)
Hi,
I tried to reproduce the error with a reduced test-case:
#include arm_neon.h
float32x2_t a, b, c, e;
int main()
{
e = __builtin_neon_vmls_lanev2sf (a, b, c, 0);
return 0;
}
arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c
arm-linux-gnueabihf-gcc test.o -flto -o test
lto1: fatal error: target specific builtin not available
compilation terminated.
Ofcourse, that's expected behaviour - you don't have support for the SIMD
intrinsics if you don't ask for it on the command line or your compiler
doesn't default to generating code for the SIMD unit.
lto-wrapper: fatal error:
/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/
builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc returned
1 exit status
compilation terminated.
However passing -mfpu=neon for linking works:
arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test
I suppose similar thing must be happening during linking
libshared_memory_support.so for chromium build ?
I couldn't see -mfpu=neon in the command line used for linking
libshared_memory_support.so
RESOLVED INVALID then ?
Yeah, silly mistake from my side, sorry for the noise.
Regards,
Prathamesh
regards
Ramana
Thank you
Prathamesh
[Bug c++/65853] New: Casting operator is missing ambiguity error (and happily compiles)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65853
Bug ID: 65853
Summary: Casting operator is missing ambiguity error (and
happily compiles)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.martindale at raytheon dot com
Created attachment 35387
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35387action=edit
Source file and artifacts
In the following code, there are three lines commented out because they cause
the compiler to correctly produce an error because of the ambiguity of the
getName function. Unfortunately, I would also expect the other two casting
operator calls to generate a similar ambiguity. Instead g++ compiles and runs
the program just fine, without specifying how it chose the casting operator or
even giving an error.
The lines
std::string result1(combo1);
std::string result2(combo2);
should produce an ambiguity error (or at least a warning) rather than compile
and run.
(Note: There are multiple derivations because I was trying to figure out how
the call was actually chosen - it looks to have chosen the first one in the
derived list).
#include iostream
#include string
class Base {
public:
Base(const std::string name) : m_name(name) {}
operator const std::string () const { return m_name; }
const std::string getName() const { return m_name; }
const std::string m_name;
};
class DerivedOnce : public Base {
public:
DerivedOnce(const std::string name) : Base(name) {}
};
class DerivedAgain : public DerivedOnce {
public:
DerivedAgain(const std::string name) : DerivedOnce(name) {}
};
class DerivedElse : public Base {
public:
DerivedElse(const std::string name) : Base(name) {}
};
class CombinedOnce : public DerivedOnce, public DerivedElse {
public:
CombinedOnce(const std::string name1, const std::string name2) :
DerivedOnce(name1), DerivedElse(name2) {}
};
class CombinedAgain : public DerivedAgain, public DerivedElse {
public:
CombinedAgain(const std::string name1, const std::string name2) :
DerivedAgain(name1), DerivedElse(name2) {}
};
int main(int argc, const char *argv[]) {
CombinedOnce combo1(apple, grape);
CombinedAgain combo2(apple, grape);
std::string result1(combo1);
std::string result2(combo2);
std::cout result1 - result2 std::endl;
// std::string result3(combo1.getName());
// std::string result4(combo2.getName());
// std::cout result3 - result4 std::endl;
return 0;
}
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456
--- Comment #17 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Author: wschmidt
Date: Thu Apr 23 00:21:39 2015
New Revision: 222349
URL: https://gcc.gnu.org/viewcvs?rev=222349root=gccview=rev
Log:
[gcc]
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* config/rs6000/rs6000.c (rs6000_option_override_internal): For
VSX + POWER8, enable TARGET_ALLOW_MOVMISALIGN and
TARGET_EFFICIENT_UNALIGNED_VSX if not selected by command line
option.
(rs6000_builtin_mask_for_load): Return 0 for targets with
efficient unaligned VSX accesses so that the vectorizer will use
direct unaligned loads.
(rs6000_builtin_support_vector_misalignment): Always return true
for targets with efficient unaligned VSX accesses.
(rs6000_builtin_vectorization_cost): Cost of unaligned loads and
stores on targets with efficient unaligned VSX accesses is almost
always the same as the cost of an aligned load or store, so model
it that way.
* config/rs6000/rs6000.h (SLOW_UNALIGNED_ACCESS): Return 0 for
unaligned vectors if we have efficient unaligned VSX accesses.
* config/rs6000/rs6000.opt (mefficient-unaligned-vector): New
undocumented option.
[gcc/testsuite]
2015-04-22 Bill Schmidt wschm...@linux.vnet.ibm.com
PR target/65456
* gcc.dg/vect/bb-slp-24.c: Exclude test for POWER8.
* gcc.dg/vect/bb-slp-25.c: Likewise.
* gcc.dg/vect/bb-slp-29.c: Likewise.
* gcc.dg/vect/bb-slp-32.c: Replace vect_no_align with
vect_no_align { ! vect_hw_misalign }.
* gcc.dg/vect/bb-slp-9.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-slp-33.c: Exclude test for
vect_hw_misalign.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c: Likewise.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Adjust tests to
account for POWER8, where peeling for alignment is not needed.
* gcc.dg/vect/costmodel/ppc/costmodel-vect-outer-fir.c: Replace
vect_no_align with vect_no_align { ! vect_hw_misalign }.
* gcc.dg.vect.if-cvt-stores-vect-ifcvt-18.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6-global.c: Likewise.
* gcc.dg/vect/no-scevccp-outer-6.c: Likewise.
* gcc.dg/vect/no-vfa-vect-43.c: Likewise.
* gcc.dg/vect/no-vfa-vect-57.c: Likewise.
* gcc.dg/vect/no-vfa-vect-61.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-1.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-2.c: Likewise.
* gcc.dg/vect/no-vfa-vect-depend-3.c: Likewise.
* gcc.dg/vect/pr16105.c: Likewise.
* gcc.dg/vect/pr20122.c: Likewise.
* gcc.dg/vect/pr33804.c: Likewise.
* gcc.dg/vect/pr33953.c: Likewise.
* gcc.dg/vect/pr56787.c: Likewise.
* gcc.dg/vect/pr58508.c: Likewise.
* gcc.dg/vect/slp-25.c: Likewise.
* gcc.dg/vect/vect-105-bit-array.c: Likewise.
* gcc.dg/vect/vect-105.c: Likewise.
* gcc.dg/vect/vect-27.c: Likewise.
* gcc.dg/vect/vect-29.c: Likewise.
* gcc.dg/vect/vect-33.c: Exclude unaligned access test for
POWER8.
* gcc.dg/vect/vect-42.c: Replace vect_no_align with vect_no_align
{ ! vect_hw_misalign }.
* gcc.dg/vect/vect-44.c: Likewise.
* gcc.dg/vect/vect-48.c: Likewise.
* gcc.dg/vect/vect-50.c: Likewise.
* gcc.dg/vect/vect-52.c: Likewise.
* gcc.dg/vect/vect-56.c: Likewise.
* gcc.dg/vect/vect-60.c: Likewise.
* gcc.dg/vect/vect-72.c: Likewise.
* gcc.dg/vect/vect-75-big-array.c: Likewise.
* gcc.dg/vect/vect-75.c: Likewise.
* gcc.dg/vect/vect-77-alignchecks.c: Likewise.
* gcc.dg/vect/vect-77-global.c: Likewise.
* gcc.dg/vect/vect-78-alignchecks.c: Likewise.
* gcc.dg/vect/vect-78-global.c: Likewise.
* gcc.dg/vect/vect-93.c: Likewise.
* gcc.dg/vect/vect-95.c: Likewise.
* gcc.dg/vect/vect-96.c: Likewise.
* gcc.dg/vect/vect-cond-1.c: Likewise.
* gcc.dg/vect/vect-cond-3.c: Likewise.
* gcc.dg/vect/vect-cond-4.c: Likewise.
* gcc.dg/vect/vect-cselim-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-1.c: Likewise.
* gcc.dg/vect/vect-multitypes-3.c: Likewise.
* gcc.dg/vect/vect-multitypes-4.c: Likewise.
* gcc.dg/vect/vect-multitypes-6.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-1.c: Likewise.
* gcc.dg/vect/vect-nest-cycle-2.c: Likewise.
* gcc.dg/vect/vect-outer-3a-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-3a.c: Likewise.
* gcc.dg/vect/vect-outer-5.c: Likewise.
* gcc.dg/vect/vect-outer-fir-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb-big-array.c: Likewise.
* gcc.dg/vect/vect-outer-fir-lb.c: Likewise.
* gcc.dg/vect/vect-outer-fir.c: Likewise.
* gcc.dg/vect/vect-peel-3.c: Likewise.
* gcc.dg/vect/vect-peel-4.c: Likewise.
* gcc.dg/vect/vect-pre-interact.c: Likewise.
* gcc.target/powerpc/pr65456.c: New test.
* gcc.target/powerpc/vsx-vectorize-2.c: Exclude test for POWER8.
* gcc.target/powerpc/vsx-vectorize-4.c: Likewise.
* gcc.target/powerpc/vsx-vectorize-6.c: Likewise.
*
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I am thinking its not working, but maybe I do not understand the function. I created a loop like this (with the patch): q1 = 233181505644407.q0 q2 = anint (q1) q3 = 233181505644408.q0 do i=1,1000 q1=q1+.02400039q0 q2=anint(q1) write (6, '(f50.25)') q1, q2 write (6, '(z35)') q1, q2 end do Scrolling through the results, I spot this: 233181505644431.73638570995104932 233181505644431.5 402EA827999FCF1F79078C3B622BC417 402EA827999FCF1F
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #10 from Paul Robinson paul_robinson at playstation dot sony.com --- I thought I had heard your name before! Howdy... Granted this is an obscure corner case, but they are legal filenames, using a leading # is less horrifying than a leading space, and the depfile that gcc produces is demonstrably wrong. I just downloaded Cygwin with gcc 4.9.2 to my Windows, and the behavior is exactly the same (using \ instead of / as the separator, seeing \\\ before the space and only \\ before the #). Anyway, can we agree that the inconsistent handling of space and # is a bug? You can set the priority as low as you like. FYI, you do _not_ want to escape all backslashes; that will break BSD Make, which doesn't do any quoting at all.
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Wed, Apr 22, 2015 at 11:19:13PM +, bugs at dhbailey dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #3 from dhbbugs bugs at dhbailey dot com --- Has anyone else been able to confirm that Steve Kargl's fix will work? What has to happen to move this fix into the production code? I haven't submitted the patch to gcc-patches@, so I suspect no one has looked at it (especially with gcc 5.1 being released). I simply attached the patch to the audit trail of the bug report because I haven't been able to convince myself that it is correct.
[Bug c++/65854] New: [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65854
Bug ID: 65854
Summary: [c++-concepts] Type constraint satisfaction error for
type aliases; regression from r211824
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
The following test case demonstrates what I believe to be an error in type
constraint satisfaction involving type aliases. I believe the code should be
rejected with the noted error. I have an old gcc build (r211824) that does
reject it (though the 'typename' keyword in the concept definition must be
removed for the compiler to reject it for the correct reason). gcc r222333
(incorrectly) accepts it.
The test case defines a binary type trait template class (BTT), an alias
template that references it (Alias), a concept (C) that specifies a type
constraint using the alias, and declares a template function (f) that requires
the concept for its template parameters. The call to fchar,int() should be
rejected due to a failure of the type constraint in C (BTTchar,int::type
won't exist), but gcc r222333 fails to reject.
Changing the concept to bypass the template alias and require 'typename
BTTT1,T2::type' instead suffices for gcc r222333 to correctly reject the
code.
$ cat t.cpp
templatetypename T1, typename T2
struct BTT {};
templatetypename T
struct BTTT,T {
using type = int;
};
templatetypename T1, typename T2
using Alias = typename BTTT1, T2::type;
templatetypename T1, typename T2
concept bool C() {
return requires() {
typename AliasT1, T2;
};
}
templatetypename T1, typename T2
requires CT1, T2()
int f();
auto i = fchar, int(); // error: cannot call function
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 222333
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 222332
Last Changed Date: 2015-04-22 12:08:55 -0400 (Wed, 22 Apr 2015)
$ g++ -c -std=c++1z t.cpp
no error
# Using an older gcc r211824 build (and having removed the 'typename' keyword
# preceding Alias in the concept definition that this old build didn't allow),
# the code is rejected (though the error message is a little off). (note
# that this old build required -std=c++1y to enable support for concepts).
$ g++ -c -std=c++1y t.cpp
t.cpp:22:23: error: no matching function for call to ‘f()’
auto i = fchar, int();
^
t.cpp:20:5: note: candidate: templateclass T1, class T2 int f()
int f();
^
t.cpp:20:5: note: template argument deduction/substitution failed:
t.cpp:20:5: note: constraints not satisfied [with T1 = char; T2 = int]
t.cpp:20:5: note: failure in constraint ‘templateclass T1, class T2
constexpr bool C()’
t.cpp:20:5: note: ‘BTTchar, int::Alias’ does not name a valid type
[Bug c++/65848] [c++-concepts] High memory usage and compilation times for subsuming concept chains; regression from r211824
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65848 Tom Honermann tom at honermann dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tom Honermann tom at honermann dot net --- Thank you. Confirmed fixed with r222332. My resource usage compiling the test case now closely matches the usage noted in comment 2. (In reply to Andrew Sutton from comment #1) This is caused by the use of a concept outside of a requires clause -- it's still a bug though. The TS doesn't actually include wording that would allow this program to be valid. Ah, I wasn't aware of that restriction. Unfortunately, the first thing people do when they have concepts it to write tests that statically assert them, so I've been extending the proposal to make that valid. I think that is actually not so unfortunate. Statically asserting concept models has helped me find numerous issues in my own code. I'm glad to hear the proposal is being extended to cover this.
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Typically you need a libquadmath maintainer to review the patch and approve it. I did try the patch with the small test case here, but it probably needs to get tested for other cases. Since it is a fairly serious wrong code bug, it would first need to go into GCC trunk (6.0) and then after some proving time, it could be back ported. The patch seems simple enough that one could go back a few versions I suppose.
[Bug preprocessor/65852] New: Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 Bug ID: 65852 Summary: Incorrect escaping in depfiles Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: paul_robinson at playstation dot sony.com When gcc creates a depfile, and a target or dependency has a space or # in it, the filespec in the depfile is escaped with a backslash so GNU Make won't interpret it as a delimiter or comment character. GNU Make also expects backslashes to be escaped, which can lead to some misinterpretation if a backslash in the original filename is immediately followed by a space or # character. gcc will take care to double the backslashes immediately preceding a space, but does not do the same for #, which results in a bogus depfile. $ cat tspace.c #include foo\ bar.h #include bar\#foo.h int i; $ ls bar\#foo.h foo\ bar.h tspace.c $ gcc -c -MMD tspace.c $ cat tspace.d tspace.o: tspace.c foo\\\ bar.h bar\\#foo.h $ make -f tspace.d tspace.o make: *** No rule to make target `bar\', needed by `tspace.o'. Stop. $
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Here is what the comment says in the source: /* Given a filename, quote characters in that filename which are significant to Make. Note that it's not possible to quote all such characters - e.g. \n, %, *, ?, [, \ (in some contexts), and ~ are not properly handled. It isn't possible to get this right in any current version of Make. (??? Still true? Old comment referred to 3.76.1.) */ So maybe there was an issue with make at one point. Basically \ is not mungled to be what it should be done.
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #6 from Paul Robinson paul_robinson at playstation dot sony.com --- (In reply to Andrew Pinski from comment #4) Really for portability using \ and/or # should be avoided. I accept that, however we do have Windows clients trying to use Make, so \ is a fact of life. These are admittedly obscure corner cases, however gcc took the trouble to get space right, it would be nice to get # right also.
[Bug libquadmath/65757] gfortran gives incorrect result for anint with real*16 argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65757 --- Comment #3 from dhbbugs bugs at dhbailey dot com --- Has anyone else been able to confirm that Steve Kargl's fix will work? What has to happen to move this fix into the production code?
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #8 from Paul Robinson paul_robinson at playstation dot sony.com --- (In reply to Andrew Pinski from comment #7) Hmm, I thought \ would be converted into / by the time we reach here for windows. I wonder if that is the better fix. Admittedly the gcc I have on Windows is *very* old, but it does not normalize \ to / before writing the depfile.
[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 22 20:52:52 2015 New Revision: 222337 URL: https://gcc.gnu.org/viewcvs?rev=222337root=gccview=rev Log: PR c++/59766 * decl.c (grokdeclarator): Do not flag friends with deduced return. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/auto-fn26.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/decl.c
[Bug c++/65727] [4.8/4.9/5/6 Regression] Segfault With Decltype In Lambda Expression Used To Initialize Static Class Member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65727 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 22 20:53:07 2015 New Revision: 222340 URL: https://gcc.gnu.org/viewcvs?rev=222340root=gccview=rev Log: PR c++/65727 * lambda.c (maybe_resolve_dummy): Handle null return. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-decltype2.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/lambda.c
[Bug c++/65721] [4.8/4.9/5/6 Regression] Internal compiler error segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65721 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 22 20:52:57 2015 New Revision: 222338 URL: https://gcc.gnu.org/viewcvs?rev=222338root=gccview=rev Log: PR c++/65721 * name-lookup.c (do_class_using_decl): Complain about specifying the current class even if there are dependent bases. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/lookup/using55.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/name-lookup.c
[Bug c++/65695] [4.9/5/6 Regression] NSDMI calling constexpr constructor with pointer-to-member is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65695 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Apr 22 20:53:02 2015 New Revision: 222339 URL: https://gcc.gnu.org/viewcvs?rev=222339root=gccview=rev Log: PR c++/65695 * cvt.c (cp_fold_convert): Avoid wrapping PTRMEM_CST in NOP_EXPR. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-ptrmem4.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/cvt.c
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #5 from Paul Robinson paul_robinson at playstation dot sony.com --- Compare how space and # are handled, to see the problem. They need to be handled the same way.
[Bug debug/54773] no debug info generated for rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54773 --- Comment #3 from chihin ko chihin.ko at oracle dot com --- g++ 4.8.2 on intel-Linux regress again. DW_TAG_rvalue_reference_type did not get generated. g++ 4.8.2 on intel Solaris is broken too. g++ 4.9.0 works on intel-Linux but not on intel Solaris.
[Bug fortran/65429] ICE on implied-length character empty array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Apr 22 22:43:46 2015 New Revision: 222342 URL: https://gcc.gnu.org/viewcvs?rev=222342root=gccview=rev Log: 2015-04-22 Steven G. Kargl ka...@gcc.gnu.org PR fortran/65429 * decl.c (add_init_expr_to_sym): Set the length type parameter. PR fortran/65429 * gfortran.dg/pr65429.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr65429.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- This was bug 35458 which says it was fixed in 4.4.0.
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Really for portability using \ and/or # should be avoided.
[Bug fortran/65429] ICE on implied-length character empty array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Apr 22 23:12:30 2015 New Revision: 222343 URL: https://gcc.gnu.org/viewcvs?rev=222343root=gccview=rev Log: 2015-04-22 Steven G. Kargl ka...@gcc.gnu.org PR fortran/65429 * decl.c (add_init_expr_to_sym): Set the length type parameter. PR fortran/65429 * gfortran.dg/pr65429.f90: New test. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr65429.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/59766] c++1y: declaring friend function with 'auto' return type deduction is rejected with bogus reason
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59766 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.2/6.
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 Paul Robinson paul_robinson at playstation dot sony.com changed: What|Removed |Added Version|unknown |4.8.2 --- Comment #1 from Paul Robinson paul_robinson at playstation dot sony.com --- Using GNU Make 3.8.1, which is what came with Ubuntu 14.04.
[Bug fortran/65429] ICE on implied-length character empty array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65429 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk and 5.1 branch. Closing.
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Paul Robinson from comment #8) Admittedly the gcc I have on Windows is *very* old, but it does not normalize \ to / before writing the depfile. I know it is very old, I worked on it before leaving Sony :). I did a 4.3 port and it seemed to be working better for windows but Sony want to use this port.
[Bug c++/65851] New: ice in set_lattice_value at tree-ssa-cc p.c:535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65851
Bug ID: 65851
Summary: ice in set_lattice_value at tree-ssa-cc p.c:535
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Created attachment 35386
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35386action=edit
gzipped C++ source code
The attached code, when compiled by gcc trunk dated 20150422,
with flag -O2 on x86_64, does this
bug201.cc: In member function ‘void CamWnd::Cam_Draw()’:
bug201.cc:95609:6: internal compiler error: in set_lattice_value, at
tree-ssa-cc
p.c:535
void CamWnd::Cam_Draw() {
^
0xed5857 set_lattice_value
../../src/trunk/gcc/tree-ssa-ccp.c:535
0xedacdc visit_assignment
../../src/trunk/gcc/tree-ssa-ccp.c:2290
0xedacdc ccp_visit_stmt
../../src/trunk/gcc/tree-ssa-ccp.c:2364
0xf63174 simulate_stmt
../../src/trunk/gcc/tree-ssa-propagate.c:348
This might be related to bug # 63914.
[Bug preprocessor/65852] Incorrect escaping in depfiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65852 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- Hmm, I thought \ would be converted into / by the time we reach here for windows. I wonder if that is the better fix.
[Bug c/65855] New: missing optimization: triangular numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855
Bug ID: 65855
Summary: missing optimization: triangular numbers
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shawn at churchofgit dot com
Created attachment 35388
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35388action=edit
triangle.c
If a register mode is available to avoid multiplication overflow, a loop that
is calculating triangular numbers could be optimized to a multiplication:
uint64_t triangle(uint32_t n) {
uint64_t t = 0;
for (uint64_t i=1;i=n;i++) t += i;
return t;
}
=
uint64_t triangle_fast(uint32_t _n) {
uint64_t t, n = _n;
t = (n * (n + 1)) / 2;
return t;
}
[Bug middle-end/65855] missing optimization: triangular numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65855 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Version|5.0 |5.1.0 Severity|normal |enhancement
[Bug rtl-optimization/64688] [4.9 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|5.2 |4.9.3 --- Comment #21 from Uroš Bizjak ubizjak at gmail dot com --- Backport was committed some time ago.
[Bug libstdc++/65147] alignment of std::atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|5.2 |5.0 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org --- This was fixed.
[Bug target/65847] New: SSE2 code for adding two structs is much worse at -O3 than at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65847
Bug ID: 65847
Summary: SSE2 code for adding two structs is much worse at -O3
than at -O2
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jay.foad at gmail dot com
On x86_64 I get decent code at -O2:
$ cat zplus.c
typedef struct { double a, b; } Z;
Z zplus(Z x, Z y) { return (Z){ x.a + y.a, x.b + y.b }; }
$ gcc -O2 -S -o - zplus.c
...
zplus:
.LFB0:
.cfi_startproc
addsd %xmm3, %xmm1
addsd %xmm2, %xmm0
ret
.cfi_endproc
.LFE0:
...
but awful code at -O3:
$ gcc -O3 -S -o - zplus.c
...
zplus:
.LFB0:
.cfi_startproc
movq%xmm0, -40(%rsp)
movq%xmm1, -32(%rsp)
movq%xmm2, -56(%rsp)
movq%xmm3, -48(%rsp)
movupd -40(%rsp), %xmm1
movupd -56(%rsp), %xmm0
addpd %xmm0, %xmm1
movaps %xmm1, -72(%rsp)
movq-72(%rsp), %rdx
movq-64(%rsp), %rax
movq%rdx, -72(%rsp)
movsd -72(%rsp), %xmm0
movq%rax, -72(%rsp)
movsd -72(%rsp), %xmm1
ret
...
I see similar bad code generated by various versions of GCC, starting around
version 4.8:
gcc-4.8 (Ubuntu 4.8.3-12ubuntu3) 4.8.3
gcc (Ubuntu 4.9.1-16ubuntu6) 4.9.1
gcc (GCC) 6.0.0 20150422 (experimental)
[Bug target/65847] SSE2 code for adding two structs is much worse at -O3 than at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65847 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-22 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. The issue is that the vectorizer thinks x and y reside in memory and thus it vectorizes the code as bb 2: vect__2.5_11 = MEM[(double *)x]; vect__3.8_13 = MEM[(double *)y]; vect__4.9_14 = vect__2.5_11 + vect__3.8_13; MEM[(double *)D.1840] = vect__4.9_14; return D.1840; which looks good. But now comes the ABI and passes x, y and the return value in registers ... But even the best vectorized sequence would have four stmts - two to pack arguments into vector registers, one add and one upack for the return value. Thus it seems the vectorizer should be informed of this ABI detail or simply as heuristic never consider function arguments memory it can perform vector loads on (which probably means to disable group analysis on them?). On i?86 with SSE2 we get movupd 8(%esp), %xmm1 movl4(%esp), %eax movupd 24(%esp), %xmm0 addpd %xmm1, %xmm0 movups %xmm0, (%eax) vs. movsd 16(%esp), %xmm0 movl4(%esp), %eax movsd 8(%esp), %xmm1 addsd 32(%esp), %xmm0 addsd 24(%esp), %xmm1 movsd %xmm0, 8(%eax) movsd %xmm1, (%eax) which eventually looks even profitable (with -mfpmath=sse). So a simple heuristic might pessimize things too much. Replicating calls.c code to compute how the arguments are passed sounds odd though... Eventually the target can pessimize the loads in the target cost model though (at least it can perform a more reasonable heuristic).
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837
--- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #3)
Hi,
I tried to reproduce the error with a reduced test-case:
#include arm_neon.h
float32x2_t a, b, c, e;
int main()
{
e = __builtin_neon_vmls_lanev2sf (a, b, c, 0);
return 0;
}
arm-linux-gnueabihf-gcc -mfpu=neon test.c -flto test.c -c
arm-linux-gnueabihf-gcc test.o -flto -o test
lto1: fatal error: target specific builtin not available
compilation terminated.
Ofcourse, that's expected behaviour - you don't have support for the SIMD
intrinsics if you don't ask for it on the command line or your compiler doesn't
default to generating code for the SIMD unit.
lto-wrapper: fatal error:
/home/prathamesh.kulkarni/gnu-toolchain/gcc-chromium-arm-linux-gnueabihf/
builds/destdir/x86_64-unknown-linux-gnu/bin/arm-linux-gnueabihf-gcc returned
1 exit status
compilation terminated.
However passing -mfpu=neon for linking works:
arm-linux-gnueabihf-gcc -mfpu=neon test.o -flto -o test
I suppose similar thing must be happening during linking
libshared_memory_support.so for chromium build ?
I couldn't see -mfpu=neon in the command line used for linking
libshared_memory_support.so
RESOLVED INVALID then ?
regards
Ramana
Thank you
Prathamesh
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org --- Comment #4 from vries at gcc dot gnu.org --- Created attachment 35383 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35383action=edit Tentative patch This patch seems to fix the error: ... diff --git a/gcc/gimplify.c b/gcc/gimplify.c index c68bd47..5f1dd1a 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -9352,7 +9352,9 @@ gimplify_va_arg_internal (tree valist, tree type, location_t loc, else gimplify_expr (valist, pre_p, post_p, is_gimple_min_lval, fb_lvalue); - return targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p); + tree expr = targetm.gimplify_va_arg_expr (valist, type, pre_p, post_p); + gimplify_expr (expr, pre_p, post_p, is_gimple_val, fb_rvalue); + return expr; } /* Gimplify __builtin_va_arg, aka VA_ARG_EXPR, which is not really a ... Before gimplify_expr: ... (gdb) call debug_generic_expr (expr) *(double *) (ap = ap + 4294967288 4294967288B) ... And after gimplify_expr: ... (gdb) call debug_generic_expr (expr) D.3458 (gdb) call debug_gimple_seq (*pre_p) ap.13 = ap; D.3456 = ap.13 + 4294967288; ap.14 = D.3456 4294967288B; ap = ap.14; ap.13 = ap; D.3458 = MEM[(double *)ap.13]; ...
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #5 from vries at gcc dot gnu.org --- Dave, could you please test the patch on hppa? Thanks, - Tom
[Bug target/55144] opening glibc-c.o: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55144 --- Comment #2 from Bernhard Reutner-Fischer aldot at gcc dot gnu.org --- Author: aldot Date: Wed Apr 22 08:25:40 2015 New Revision: 222313 URL: https://gcc.gnu.org/viewcvs?rev=222313root=gccview=rev Log: PR target/55144 building all-gcc for bfin-linux-uclibc resulted in build/genchecksum cp/cp-lang.o c-family/stub-objc.o ... glibc-c.o \ libbackend.a .. cc1plus-checksum.c.tmp opening glibc-c.o: No such file or directory make[2]: *** [cc1-checksum.c] Error 1 Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #7 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01258.html
[Bug rtl-optimization/64818] User specified register don't work correctly in inline-asm operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64818 --- Comment #1 from xuepeng guo xguo at gcc dot gnu.org --- Author: xguo Date: Wed Apr 22 07:21:35 2015 New Revision: 222306 URL: https://gcc.gnu.org/viewcvs?rev=222306root=gccview=rev Log: gcc/ChangeLog: 2015-04-22 Hale Wang hale.w...@arm.com Terry Guo terry@arm.com PR rtl-optimization/64818 * combine.c (can_combine_p): Don't combine user-specified register if it is in an asm input. gcc/testsuite/ChangeLog 2015-04-22 Hale Wang hale.w...@arm.com Terry Guo terry@arm.com PR rtl-optimization/64818 * gcc.target/arm/pr64818.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr64818.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug target/47122] vax-*-openbsd* configuration purports to require openbsd-pthread.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47122 --- Comment #1 from Bernhard Reutner-Fischer aldot at gcc dot gnu.org --- Author: aldot Date: Wed Apr 22 08:30:15 2015 New Revision: 222314 URL: https://gcc.gnu.org/viewcvs?rev=222314root=gccview=rev Log: PR target/47122: vax-*-openbsd* config.gcc typo Gerald / jsg typoed this in the initial r152218 a.k.a 8e6600a15374f9446d5026e8ef6b68e0d753fb6c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug c/65842] combine is overly cautious when operating on side effect operands references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65842
--- Comment #1 from vfdff zhongyunde at huawei dot com ---
(gdb) p debug_rtx (newpat)
(set (reg:SI 191 [ g_123$6+4 ])
(and:SI (mem/c:SI (pre_modify:SI (reg/f:SI 164)
(plus:SI (reg/f:SI 164)
(const_int -12 [0xfff4]))) [4 g_123+4 S4 A32])
(const_int 0 [0])))
combined to
(gdb) p debug_rtx (i3)
(insn 44 43 51 2 (set (reg:SI 191 [ g_123$6+4 ])
(const_int 0 [0])) test.c:61 30 {andsi3}
(expr_list:REG_DEAD (reg:SI 165 [ g_123+4 ])
combine_simplify_rtx in combine pass call function simplify_binary_operation_1
and simplify_and_const_int_1 to simplify operands.
in simplify_binary_operation_1, it can be simplified as the condition
side_effects_p (op0). see detail as follow:
Breakpoint 1, simplify_binary_operation_1 (code=AND, mode=SImode,
op0=0xf7f89dd4, op1=0xf7e052b8, trueop0=0xf7f89dd4, trueop1=0xf7e052b8)
at /net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/simplify-rtx.c:1933
1933 unsigned int width = GET_MODE_PRECISION (mode);
(gdb) p debug_rtx (op0)
(mem/c:SI (pre_modify:SI (reg/f:SI 164)
(plus:SI (reg/f:SI 164)
(const_int -12 [0xfff4]))) [4 g_123+4 S4 A32])
$8 = void
(gdb) n
1938 switch (code)
(gdb)
2732 if (trueop1 == CONST0_RTX (mode) ! side_effects_p (op0))
(gdb)
while in simplify_and_const_int_1, it can be simplified as no simalar condition
side_effects_p (op0), so it may be the causation.
(gdb) bt
#0 simplify_and_const_int_1 (mode=SImode, varop=0xf7f89dd4, constop=0) at
/net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/combine.c:9468
#1 0x08a517d8 in simplify_and_const_int (x=0xf7f8b780, mode=SImode,
varop=0xf7f89dd4, constop=0) at
/net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/combine.c:9578
#2 0x08a4aca4 in simplify_logical (x=0xf7f8b780) at
/net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/combine.c:6726
#3 0x08a48cb5 in combine_simplify_rtx (x=0xf7f8b780, op0_mode=VOIDmode,
in_dest=0, in_cond=0) at
/net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/combine.c:5989
#4 0x08a47370 in subst (x=0xf7f8b780, from=0xf7f43930, to=0xf7e052b8,
in_dest=0, in_cond=0, unique_copy=0) at
/net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/combine.c:5314
#5 0x08a4714b in subst (x=0xf7f7c750, from=0xf7f43930, to=0xf7e052b8,
in_dest=0, in_cond=0, unique_copy=0) at
/net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/combine.c:5250
#6 0x08a41a93 in try_combine (i3=0xf7f88384, i2=0xf7f88360, i1=0xf7e6af9c,
i0=0x0, new_direct_jump_p=0xcd14, last_combined_insn=0xf7f88384)
at /net1/home/zhongyunde/6183_hcc/gcc/gcc-4.7.0/gcc/combine.c:3271
9501 constop = nonzero;
(gdb)
9504 if (constop == 0)
[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65767 --- Comment #4 from amker at gcc dot gnu.org --- Author: amker Date: Wed Apr 22 09:37:52 2015 New Revision: 222319 URL: https://gcc.gnu.org/viewcvs?rev=222319root=gccview=rev Log: Backport from trunk r55 2015-04-21 Bin Cheng bin.ch...@arm.com PR testsuite/65767 * g++.dg/lto/pr65276_0.C: Change namespace std to std2. * g++.dg/lto/pr65276_1.C: Change namespace std to std2. Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/g++.dg/lto/pr65276_0.C branches/gcc-5-branch/gcc/testsuite/g++.dg/lto/pr65276_1.C
[Bug c/63357] Warn for P P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Depends on||61534 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Patch here https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01137.html But it's blocked until we resolve PR61534.
[Bug c++/65843] New: multiple use of const variable in lamba in template function causes compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843
Bug ID: 65843
Summary: multiple use of const variable in lamba in template
function causes compile error
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: darklin20 at gmail dot com
The source code in next report is completely valid source code but GCC
5.0.0 rejects to compile it.
Older version of GCC can compile this.
I tested this in Ubuntu but I've got the same report in fedora from other user.
If I change the type of varaible 'a' to int from const int, or make the test
function non-template, it can be compiled.
---
the exact version of GCC
5.0.0 20150329 (experimental) [trunk revision 221764] (Ubuntu
5-20150329-1ubuntu11~14.04)
the system type
x86_64-linux-gnu
the options given when GCC was configured/built
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5-20150329-1ubuntu11~14.04'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-5 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/5 --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=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
the complete command line that triggers the bug
g++-5 -std=c++11 test.cpp
the compiler output (error messages, warnings, etc.)
test.cpp: In instantiation of 'test(T)::lambda() [with T = int]':
test.cpp:5:7: required from 'struct test(T) [with T = int]::lambda()'
test.cpp:5:28: required from 'void test(T) [with T = int]'
test.cpp:9:11: required from here
test.cpp:5:27: error: redeclaration of 'const int a'
[] () { return a, a; }();
^
test.cpp:5:27: note: 'const int a' previously declared here
test.cpp: In instantiation of 'void test(T) [with T = int]':
test.cpp:9:11: required from here
test.cpp:5:5: sorry, unimplemented: non-trivial designated
initializers not supported
[] () { return a, a; }();
the preprocessed file (*.i*) that triggers the bug
# 1 test.cpp
# 1 built-in
# 1 command-line
# 1 /usr/include/stdc-predef.h 1 3 4
# 1 command-line 2
# 1 test.cpp
templateclass T
void test(T b)
{
const int a = b;
[] () { return a, a; }();
}
int main() {
test(1);
return 0;
}
[Bug c++/65843] [5/6 Regression] multiple use of const variable in lamba in template function causes compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-22 Known to work||4.9.2 Summary|multiple use of const |[5/6 Regression] multiple |variable in lamba in|use of const variable in |template function causes|lamba in template function |compile error |causes compile error Ever confirmed|0 |1 Severity|major |normal
[Bug tree-optimization/65818] [6 Regression] libiberty/vprintf-support.c:41:1: ICE: in expand_i fn_va_arg_1, at tree-stdarg.c:1095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65818 --- Comment #6 from dave.anglin at bell dot net --- On 2015-04-22, at 3:15 AM, vries at gcc dot gnu.org wrote: could you please test the patch on hppa? Started. Thanks for the patch. Dave -- John David Anglindave.ang...@bell.net
[Bug c++/61940] Wrong error location for error in initialization list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug lto/65844] New: [5 Regression] ICE (verify_cgraph_node failed) on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65844 Bug ID: 65844 Summary: [5 Regression] ICE (verify_cgraph_node failed) on i686-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen with 5.1 rc2 on i686-linux-gnu, works on x86_64, arm, ppc64le, arm64, powerpc. building python 3.5 alpha 4 with lto and pgo (using the testsuite to collect the perf data): lto1: error: indirect call frequency 1001 does not match BB frequency 1000 bytes_dealloc/5157 (bytes_dealloc) @0xf6b660e4 Type: function definition analyzed Visibility: prevailing_def_ironly previous sharing asm name: 57969 Address is taken. References: Referring: PyBytes_Type/5273 (addr)_textiowrapper_writeflush/54957 (addr) (speculative)code_dealloc/6404 (addr) (speculative)_io_FileIO___init___impl/53523 (addr) (speculative)match_dealloc/48926 (addr) (speculative)os_stat/46510 (addr) (speculative)PyBuffer_Release/59115 (addr) (speculative)bytesio_dealloc/59792 (addr) (speculative)_Pickler_ClearBuffer/39048 (addr) (speculative)s_dealloc/37732 (addr) (speculative)assemble_free/22984 (addr) (speculative)code_dealloc/6404 (addr) (speculative)decode_unicode.isra.8/21159 (addr) (speculative) Availability: available Profile id: 1495503281 First run: 402 Function flags: body icf_merged hot Called by: Calls: Indirect call(1.00 per call) lto1: internal compiler error: verify_cgraph_node failed 0x82a24dc cgraph_node::verify_node() ../../src/gcc/cgraph.c:3151 0x8296e88 symtab_node::verify() ../../src/gcc/symtab.c:1103 0x82982a4 symtab_node::verify_symtab_nodes() ../../src/gcc/symtab.c:1123 0x84cd553 symbol_table::remove_unreachable_nodes(_IO_FILE*) ../../src/gcc/ipa.c:686 0x8596895 execute_todo ../../src/gcc/passes.c:2025 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c/61864] Feature Request, -Wcovered-switch-default to identify dead default branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61864 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug target/65582] [5/6 Regression] testsuite lto issue: xgcc.exe: warning: '-x lto' after last input file has no effect, fatal error: no input files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65582 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug libffi/65726] [5/6 Regression] libffi fails to build when not bootstrapping: configure: error: C++ preprocessor /lib/cpp fails sanity check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65726 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug target/65162] [5/6 Regression][SH] Redundant tests when storing bswapped T bit result in unaligned mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65162 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug target/61821] gcc.target/i386/pr61599-1.c FAILs with Sun as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61821 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug c++/65598] Fix column location for 'explicit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65598 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug ada/48002] internal error on calling inherited, overloaded and abstract subprograms with string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48002 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|5.0 |5.2 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- GCC 5.1 has been released.
[Bug rtl-optimization/64916] ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 --- Comment #7 from Alex Velenko Alex.Velenko at arm dot com --- Just to note, my fix was earlier, yet none replied: https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00441.html
[Bug tree-optimization/65823] [6 Regression] ICE in gcc.c-torture/execute/stdarg-2.c -O0/-O1 for arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65823 --- Comment #8 from vries at gcc dot gnu.org --- Author: vries Date: Wed Apr 22 09:03:01 2015 New Revision: 222318 URL: https://gcc.gnu.org/viewcvs?rev=222318root=gccview=rev Log: Fix va_arg ap_copy nop detection 2015-04-22 Tom de Vries t...@codesourcery.com PR tree-optimization/65823 * gimplify.c (gimplify_modify_expr): Use operand_equal_p to test for equality between ap_copy and ap. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c
[Bug target/65836] [6 Regression] gnat fails to build on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65836 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-22 Ever confirmed|0 |1 --- Comment #3 from ktkachov at gcc dot gnu.org --- Confirmed, this is a bootstrap failure though (ada isn't the problem)
