[Bug fortran/62278] gfc_check_dependency should also check for TARGET attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62278 --- Comment #1 from Tobias Burnus --- Note: The code deciding whether a temporary is required seems to do additional checks, at least for the simple noncoarray assignment, no temporary is generated.
[Bug fortran/62278] New: gfc_check_dependency should also check for TARGET attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62278 Bug ID: 62278 Summary: gfc_check_dependency should also check for TARGET attribute Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: tkoenig at gcc dot gnu.org When playing around with https://gcc.gnu.org/ml/fortran/2014-08/msg00109.html, using gfc_check_dependency (lhs_expr, rhs_expr, false) I saw that for the following, the "P(:)" and "A(:)" expressions are regarded as potentially depending on each other. However, I fail how that should be possible as "A" neither has the TARGET nor the POINTER attribute. integer, save :: A(10)[*] integer, pointer :: P(:) P(:) = A(:)[i] end
[Bug rtl-optimization/62265] [4.8/4.9/5 regression] FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree "Elimination opportunities = 3 realized = 3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62265 amker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-27 CC||amker at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from amker at gcc dot gnu.org --- Confirmed on many arm/aarch64 triplets.
[Bug c++/62277] New: [C++11] constexpr member methods are treated as const, regardless of const modifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62277
Bug ID: 62277
Summary: [C++11] constexpr member methods are treated as const,
regardless of const modifier
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: juchem at gmail dot com
The following code fails to compile. Tested in Debian sid (g++ 4.8.3-9 and
4.9.1-9) and in http://ideone.com (gcc 4.8.1).
Defining CONSTEXPR to an empty macro compiles and runs successfully.
--
#include
#define CONSTEXPR constexpr
struct foo {
CONSTEXPR char const *bar() const { return "const"; }
CONSTEXPR char const *bar() { return "non-const"; }
};
int main() {
foo f;
std::cout << f.bar() << std::endl;
foo const b;
std::cout << b.bar() << std::endl;
return 0;
}
--
output:
prog.cpp:7:24: error: ‘constexpr const char* foo::bar() const’ cannot be
overloaded
CONSTEXPR char const *bar() { return "non-const"; }
^
prog.cpp:6:24: error: with ‘constexpr const char* foo::bar() const’
CONSTEXPR char const *bar() const { return "const"; }
gcc versions in debian:
$ g++-4.8 --version
g++-4.8 (Debian 4.8.3-9) 4.8.3
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4.9 --version
g++-4.9 (Debian 4.9.1-9) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/57460] [C++11] Sfinae doesn't respect dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57460 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jason Merrill --- But there is no T that would cause check<(EXPR,T())> to be valid, so no valid specialization can be generated for the template, so the program is ill-formed (no diagnostic required).
[Bug target/55143] vms-c.o:(.toc+0x0): undefined reference to `c_default_pointer_mode' (building cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55143 Jan-Benedict Glaw changed: What|Removed |Added CC||jbg...@lug-owl.de --- Comment #2 from Jan-Benedict Glaw --- With today's GCC (2014-08-26, r214550, build http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=347199), this is still present: g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-cilkplus.o cp/cp-gimplify.o cp/cp-array-notation.o cp/lambda.o cp/vtable-class-hierarchy.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o vms-c.o default-c.o cc1plus-checksum.o libbackend.a main.o tree-browser.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a-L/opt/cfarm/mpc/lib -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz /usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only handles version 2 and 3 information. vms-c.o: In function `handle_pragma_pointer_size(char const*)': vms-c.c:(.text+0x6cd): undefined reference to `c_default_pointer_mode' /usr/bin/ld: Dwarf Error: found dwarf version '0', this reader only handles version 2 and 3 information. vms-c.c:(.text+0x6e2): undefined reference to `c_default_pointer_mode' /usr/bin/ld: Dwarf Error: found dwarf version '17874', this reader only handles version 2 and 3 information. vms-c.c:(.text+0x6fa): undefined reference to `c_default_pointer_mode' /usr/bin/ld: Dwarf Error: found dwarf version '33796', this reader only handles version 2 and 3 information. vms-c.c:(.text+0x718): undefined reference to `c_default_pointer_mode' /usr/bin/ld: Dwarf Error: found dwarf version '22528', this reader only handles version 2 and 3 information. vms-c.o: In function `vms_c_common_override_options()': vms-c.c:(.text+0x9fc): undefined reference to `c_default_pointer_mode' /usr/bin/ld: Dwarf Error: found dwarf version '12288', this reader only handles version 2 and 3 information. vms-c.o:vms-c.c:(.text+0xa12): more undefined references to `c_default_pointer_mode' follow collect2: error: ld returned 1 exit status make[2]: *** [cc1plus] Error 1
[Bug target/62262] aarch64 gcc generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to Carrot from comment #5)
> (In reply to amker from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
> > > (and:SI (ashift:SI (reg/v:SI 74 [ value ])
> > > (const_int 32 [0x20]))
> > > (const_int 8388607 [0x7f]))) t7.c:13 611
> > > {*andim_ashiftsi_bfiz}
> > > (expr_list:REG_DEAD (reg/v:SI 74 [ value ])
> > > (nil)))
> > >
> > > Confirmed.
> > >
> > > "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
> > >&& (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"
> > >
> > >
> > > In fact we invoke undefined behavior inside the compiler too due to the
> > > shift there.
> >
> > Since it's undefined code, how should we handle it in GCC? Should we give
> > warning messages as accurate as possible? But that sounds impractical
> > either, since "value << 1" and "value <<= zeros" could be undefined too.
>
> Actually the original source code is guarded by assert, and the parameter
> passed to CLZ can be guaranteed not 0, so "value <<= zeros" is well defined
> in our original source code.
What I mean is by standard, E1<
[Bug c++/62276] ICE when non-variadic template template parameter is default argument of variadic template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62276 --- Comment #1 from juchem at gmail dot com --- Scratch the list of compilers tested (copy pasto). This is the actual compiler I tested on: $ g++ --version g++ (Debian 4.9.1-9) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/62274] [C++11] Variadic templates expansion into non-variadic class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62274 --- Comment #1 from juchem at gmail dot com --- Scratch the list of compilers tested (copy pasto). This is the actual compiler I tested on: $ g++ --version g++ (Debian 4.9.1-9) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/62276] New: ICE when non-variadic template template parameter is default argument of variadic template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62276
Bug ID: 62276
Summary: ICE when non-variadic template template parameter is
default argument of variadic template template
parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: juchem at gmail dot com
Created attachment 33399
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33399&action=edit
preprocessed source
The code below will result in an internal compiler error on gcc 4.9.0, 4.8.1
and 4.7.3. Tested in Debian sid (aug/2014), http://gcc.godbolt.org/ and
http://ideone.com.
template using bar = T;
template class F = bar>
void foo() {}
int main() { foo(); }
output:
$ g++-4.9 -std=c++11 ice.cpp
ice.cpp: In instantiation of ‘void foo() [with F = bar]’:
ice.cpp:6:18: required from here
ice.cpp:4:6: internal compiler error: in write_name, at cp/mangle.c:800
void foo() {}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccKK6fS1.out file, please attach this to
your bugreport.
[Bug target/62275] New: ARM should use vcvta instructions when possible for float -> int rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62275 Bug ID: 62275 Summary: ARM should use vcvta instructions when possible for float -> int rounding Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: josh.m.conner at gmail dot com Instead of generating a library call for lround/lroundf, the ARM backend should use vcvta.s32.f64 and vcvta.s32.f32 instructions instead (as long as -fno-math-errno has been given, since this obviously won't set errno).
[Bug target/62262] aarch64 gcc generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262 --- Comment #7 from Andrew Pinski --- Also the reason why it shows up in the first place is because the gimple level tracer produces: : # iftmp.0_13 = PHI <32(3)> value_5 = value_3 << iftmp.0_13; packed_6 = value_5 & 8388607; And never props the constant from the PHI node until RTL combine.
[Bug target/62262] aarch64 gcc generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262 --- Comment #6 from Andrew Pinski --- (In reply to Carrot from comment #5) > Actually the original source code is guarded by assert, and the parameter > passed to CLZ can be guaranteed not 0, so "value <<= zeros" is well defined > in our original source code. The issue is the second CLZ (not the first one). Though if I read the code correctly value<<1 can never be zero but GCC does not optimize away that check.
[Bug c++/62274] New: [C++11] Variadic templates expansion into non-variadic class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62274
Bug ID: 62274
Summary: [C++11] Variadic templates expansion into non-variadic
class template
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: juchem at gmail dot com
The code below won't compile for gcc 4.9.0, 4.8.1 and 4.7.3. Tested in Debian
sid (aug/2014), http://gcc.godbolt.org/ and http://ideone.com.
#include
using namespace std;
struct bar { typedef double foo; };
template
using get_foo = typename T::foo;
template class T>
struct baz {
template
using type = T;
};
int main() {
return !std::is_same::type>::value;
}
error output:
prog.cpp: In substitution of ‘template using get_foo = typename T::foo
[with T = UArgs ...]’:
prog.cpp:13:26: required from ‘struct baz’
prog.cpp:17:49: required from here
prog.cpp:8:32: error: ‘UArgs ...’ is not a class, struct, or union type
using get_foo = typename T::foo;
^
prog.cpp: In function ‘int main()’:
prog.cpp:17:59: error: template argument 2 is invalid
static_assert(std::is_same::type>::value,
"mismatch");
[Bug c/62273] New: doc: Invoke.texi -mkernel mentions undocumented option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62273 Bug ID: 62273 Summary: doc: Invoke.texi -mkernel mentions undocumented option Product: gcc Version: 4.7.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org As best I can tell, this is broken in every version from the tail of the 4.7-branch to the head today. -mkernel is documented as: Enable kernel development mode. The '-mkernel' option sets '-static', '-fno-common', '-fno-cxa-atexit', '-fno-exceptions', '-fno-non-call-exceptions', '-fapple-kext', '-fno-weak' and '-fno-rtti' where applicable. This mode also sets '-mno-altivec', '-msoft-float', '-fno-builtin' and '-mlong-branch' for PowerPC targets. Unfortunately, -fapple-kext does not appear anywhere in the manual. It is listed in darwin.opt with this: fapple-kext Target Report C++ Var(flag_apple_kext) Generate code for darwin loadable kernel extensions I assume someone responsible for the Darwin configuration knows enough to add a line or two of documentation.
[Bug target/62262] aarch64 gcc generates invalid assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62262
--- Comment #5 from Carrot ---
(In reply to amker from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > (insn 27 26 40 5 (set (reg:SI 73 [ D.2590 ])
> > (and:SI (ashift:SI (reg/v:SI 74 [ value ])
> > (const_int 32 [0x20]))
> > (const_int 8388607 [0x7f]))) t7.c:13 611
> > {*andim_ashiftsi_bfiz}
> > (expr_list:REG_DEAD (reg/v:SI 74 [ value ])
> > (nil)))
> >
> > Confirmed.
> >
> > "exact_log2 ((INTVAL (operands[3]) >> INTVAL (operands[2])) + 1) >= 0
> >&& (INTVAL (operands[3]) & ((1 << INTVAL (operands[2])) - 1)) == 0"
> >
> >
> > In fact we invoke undefined behavior inside the compiler too due to the
> > shift there.
>
> Since it's undefined code, how should we handle it in GCC? Should we give
> warning messages as accurate as possible? But that sounds impractical
> either, since "value << 1" and "value <<= zeros" could be undefined too.
Actually the original source code is guarded by assert, and the parameter
passed to CLZ can be guaranteed not 0, so "value <<= zeros" is well defined in
our original source code.
[Bug c++/62241] C++14 generalized lambda capture doesn't work with uniform initialization syntax.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #5 from Daniel Krügler --- (In reply to Andrew Pinski from comment #2) > Have you tried 5.x yet? Trying 5.0.0 20140826 (experimental) the outcome is still the same rejection
[Bug c++/62272] New: Gimplify throws error on method call from inside nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272
Bug ID: 62272
Summary: Gimplify throws error on method call from inside
nested lambdas
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: aaron.plavnick at spottradingllc dot com
Here is a minimal code sample, the bug exists in 4.7.3, 4.8.2, and 4.9.1. I
compiled with -std=c++11
template< typename T >
class B
{
public:
void Foo() {}
void Bar()
{
[&]()
{
[&]() { Foo(); }();
}();
}
};
int main( int argc, char** argv )
{
B b;
b.Bar();
return 0;
}
--
The compiler returns:
main.cpp: In lambda function:
main.cpp:11:34: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1741
[&]() { Foo(); }();
^
0x81b03d gimplify_var_or_parm_decl
../../../../src/gcc-4.9.1/gcc/gimplify.c:1741
0x81d931 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../../src/gcc-4.9.1/gcc/gimplify.c:8058
0x81cb40 gimplify_modify_expr
../../../../src/gcc-4.9.1/gcc/gimplify.c:4527
0x81d97a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../../src/gcc-4.9.1/gcc/gimplify.c:7627
0x820876 gimplify_stmt(tree_node**, gimple_statement_base**)
../../../../src/gcc-4.9.1/gcc/gimplify.c:5373
0x820a3a gimplify_and_add
../../../../src/gcc-4.9.1/gcc/gimplify.c:385
0x820a3a gimplify_init_ctor_eval
../../../../src/gcc-4.9.1/gcc/gimplify.c:3558
0x81c0f2 gimplify_init_constructor
../../../../src/gcc-4.9.1/gcc/gimplify.c:3904
0x81c98e gimplify_modify_expr_rhs
../../../../src/gcc-4.9.1/gcc/gimplify.c:4167
0x81ca64 gimplify_modify_expr
../../../../src/gcc-4.9.1/gcc/gimplify.c:4486
0x81d97a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../../src/gcc-4.9.1/gcc/gimplify.c:7627
0x81da18 gimplify_target_expr
../../../../src/gcc-4.9.1/gcc/gimplify.c:5304
0x81da18 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../../src/gcc-4.9.1/gcc/gimplify.c:7994
0x81e4b3 gimplify_addr_expr
../../../../src/gcc-4.9.1/gcc/gimplify.c:4833
0x81e4b3 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../../src/gcc-4.9.1/gcc/gimplify.c:7673
0x8235ba gimplify_call_expr
../../../../src/gcc-4.9.1/gcc/gimplify.c:2395
0x81db82 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../../src/gcc-4.9.1/gcc/gimplify.c:7598
0x820876 gimplify_stmt(tree_node**, gimple_statement_base**)
../../../../src/gcc-4.9.1/gcc/gimplify.c:5373
0x81dc0a gimplify_cleanup_point_expr
../../../../src/gcc-4.9.1/gcc/gimplify.c:5149
0x81dc0a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../../../src/gcc-4.9.1/gcc/gimplify.c:7990
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #31 from Ilya Mikhaltsou --- (In reply to James Clarke from comment #29) > (In reply to Jack Howarth from comment #28) > > I noticed that MacPorts is using… > > > > #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) || > > __DARWIN_64_BIT_INO_T) > > > > and > > > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > > > rather than just… > > > > > > #if SANITIZER_MAC && __DARWIN_64_BIT_INO_T > > > > and > > > > # if __DARWIN_64_BIT_INO_T > > > > in their patch for gcc49… > > > > https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10. > > diff > > > > Should we be doing the same? > > That's because they're using my original patch from this bug report > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is > based off Ilya Mikhaltsou's patch > (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug > report). I don't know why Ilya decided to default to a 64-bit dirent struct, > as the documentation clearly states that it is only 64-bit when the > _DARWIN_FEATURE_64_BIT_INODE macro is defined > (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ > ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from > __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that > _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when > __DARWIN_64_BIT_INO_T is true. > > Please note that I have updated my patch to use the public > _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined > rather than its value (seeing as the documentation only refers to its > definition, not its value). The updated patches are at > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html. I wasn't doing much thinking on the topic, I've simply made the minimal necessary changes to a) compile on 10.10 and b) to work exactly the same as before on previous versions. If you think it is redundant, there are no objective reasons for keeping it that way.
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624 --- Comment #11 from Jason Merrill --- Fixed for 4.9.2. Still broken on trunk because of the set_decl_tls_model issue, which I will leave to honza.
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624 --- Comment #10 from Jason Merrill --- Author: jason Date: Tue Aug 26 20:05:13 2014 New Revision: 214546 URL: https://gcc.gnu.org/viewcvs?rev=214546&root=gcc&view=rev Log: PR c++/58624 * pt.c (tsubst_copy_and_build) [VAR_DECL]: Use TLS wrapper. * semantics.c (finish_id_expression): Don't call TLS wrapper in a template. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/tls/thread_local10.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/pt.c branches/gcc-4_9-branch/gcc/cp/semantics.c
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624 --- Comment #9 from Jason Merrill --- Author: jason Date: Tue Aug 26 19:39:36 2014 New Revision: 214543 URL: https://gcc.gnu.org/viewcvs?rev=214543&root=gcc&view=rev Log: PR c++/58624 * pt.c (tsubst_decl) [VAR_DECL]: Copy TLS model. (tsubst_copy_and_build) [VAR_DECL]: Use TLS wrapper. * semantics.c (finish_id_expression): Don't call TLS wrapper in a template. Added: trunk/gcc/testsuite/g++.dg/tls/thread_local10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #30 from Jack Howarth --- The proposed changes in v4 of the patch aren't building here on 10.9. I don't see how # if defined(_DARWIN_FEATURE_64_BIT_INODE) can completely substitute for… # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T as sys/cdefs.h shows… /* * _DARWIN_FEATURE_64_BIT_INODE indicates that the ino_t type is 64-bit, and * structures modified for 64-bit inodes (like struct stat) will be used. */ #if __DARWIN_64_BIT_INO_T #define _DARWIN_FEATURE_64_BIT_INODE1 #endif which means that… # if defined(_DARWIN_FEATURE_64_BIT_INODE) is effectively only # if __DARWIN_64_BIT_INO_T as the definition of _DARWIN_FEATURE_64_BIT_INODE only checks if __DARWIN_64_BIT_INO_T is set and not if it is undefined as well.
[Bug c++/62271] 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62271 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Markus Trippelsdorf --- Thanks. Duplicate. *** This bug has been marked as a duplicate of bug 62075 ***
[Bug tree-optimization/62075] [4.8/4.9 Regression] Vectorizer ICE on dolphin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62075 Markus Trippelsdorf changed: What|Removed |Added CC||loic.blot@unix-experience.f ||r --- Comment #6 from Markus Trippelsdorf --- *** Bug 62271 has been marked as a duplicate of this bug. ***
[Bug c++/62271] 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62271 --- Comment #5 from loic.b...@unix-experience.fr --- Sorry. This was fixed
[Bug c++/62271] 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62271 --- Comment #4 from Markus Trippelsdorf --- The testcase is corrupted: RegisterView.ii:1:1: error: ‘_int128’ does not name a type
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #29 from James Clarke --- (In reply to Jack Howarth from comment #28) > I noticed that MacPorts is using… > > #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) || > __DARWIN_64_BIT_INO_T) > > and > > # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T > > rather than just… > > > #if SANITIZER_MAC && __DARWIN_64_BIT_INO_T > > and > > # if __DARWIN_64_BIT_INO_T > > in their patch for gcc49… > > https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10. > diff > > Should we be doing the same? That's because they're using my original patch from this bug report (https://gcc.gnu.org/bugzilla/attachment.cgi?id=33180), which itself is based off Ilya Mikhaltsou's patch (https://gcc.gnu.org/bugzilla/attachment.cgi?id=32949, also from this bug report). I don't know why Ilya decided to default to a 64-bit dirent struct, as the documentation clearly states that it is only 64-bit when the _DARWIN_FEATURE_64_BIT_INODE macro is defined (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man5/dir.5.html#//apple_ref/doc/man/5/dir). This is different from __DARWIN_64_BIT_INO_T, but you can see in sys/cdefs.h that _DARWIN_FEATURE_64_BIT_INODE is only defined (to 1) when __DARWIN_64_BIT_INO_T is true. Please note that I have updated my patch to use the public _DARWIN_FEATURE_64_BIT_INODE macro, and to check whether it is defined rather than its value (seeing as the documentation only refers to its definition, not its value). The updated patches are at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02427.html.
[Bug c++/62271] 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62271 --- Comment #3 from loic.b...@unix-experience.fr --- Hi, sorry to forget those useful informations. You can found Register.ii there: http://ftp.z-eye.org/tmp/RegisterView.ii And here is the command line: cd /home/nerzhul/Devel/dolphin/Build/Source/Core/DolphinWX && /usr/bin/c++ -DDATA_DIR=\"/usr/local/share/dolphin-emu/\" -DHAVE_ALSA=1 -DHAVE_AO=1 -DHAVE_BLUEZ=1 -DHAVE_LIBAV -DHAVE_OPENAL=1 -DHAVE_PORTAUDIO=1 -DHAVE_PULSEAUDIO=1 -DHAVE_SDL=1 -DHAVE_WX=1 -DHAVE_X11=1 -DHAVE_X11_XINPUT2=1 -DHAVE_XRANDR=1 -DUSER_DIR=\".dolphin-emu\" -DUSE_UPNP -DWXUSINGDLL -D_ARCH_64=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_M_X86=1 -D_M_X86_64=1 -D__LIBUSB__ -D__WXGTK__ -Wtype-limits -Wsign-compare -Wignored-qualifiers -Wuninitialized -Wlogical-op -Wshadow -Winit-self -Wmissing-declarations -fvisibility-inlines-hidden -fvisibility=hidden -march=native -O2 -fno-devirtualize -save-temps -pthread -O3 -DNDEBUG -I/home/nerzhul/Devel/dolphin/Externals/GL -I/usr/include/AL -I/home/nerzhul/Devel/dolphin/Source/Core -I/home/nerzhul/Devel/dolphin/Externals/Bochs_disasm -I/usr/include/soundtouch -I/usr/include/SDL2 -I/usr/include/libusb-1.0 -I/home/nerzhul/Devel/dolphin/Externals/SFML/include -I/usr/include/miniupnpc -I/home/nerzhul/Devel/dolphin/Externals/polarssl/include -I/home/nerzhul/Devel/dolphin/Externals/SOIL -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -isystem /usr/lib/wx/include/gtk2-unicode-3.0 -isystem /usr/include/wx-3.0 -I/home/nerzhul/Devel/dolphin/Build/Source/Core/Common -I/home/nerzhul/Devel/dolphin/Externals/gtest/include-msse2 -Wall -fno-strict-aliasing -fno-exceptions -fomit-frame-pointer -fopenmp -std=gnu++0x -o CMakeFiles/dolphin-emu.dir/Debugger/RegisterView.cpp.o -c /home/nerzhul/Devel/dolphin/Source/Core/DolphinWX/Debugger/RegisterView.cpp
[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188
--- Comment #11 from Steve Kargl ---
On Tue, Aug 26, 2014 at 10:53:58AM -0700, Steve Kargl wrote:
> On Tue, Aug 26, 2014 at 07:51:45AM -0700, Steve Kargl wrote:
> > On Tue, Aug 26, 2014 at 01:08:22PM +, burnus at gcc dot gnu.org wrote:
> > >
> > > Steve, should we also add a test case for the "n1 < 0"?
> > >
> >
>
> Checking in general looks broken for bessel_yn and probably _jn.
>
I'm going to have to re-learn the internals of the intrinsics stuff.
>From intrinsic.c, we have
add_sym_2 ("besjn", GFC_ISYM_JN, CLASS_ELEMENTAL, ACTUAL_NO, BT_REAL, dr,
GFC_STD_GNU,
gfc_check_besn, gfc_simplify_bessel_jn, gfc_resolve_besn,
n, BT_INTEGER, di, REQUIRED, x, BT_REAL, dr, REQUIRED);
make_alias ("bessel_jn", GFC_STD_F2008);
add_sym_2 ("dbesjn", GFC_ISYM_JN, CLASS_ELEMENTAL, ACTUAL_NO, BT_REAL, dd,
GFC_STD_GNU,
gfc_check_besn, gfc_simplify_bessel_jn, gfc_resolve_besn,
n, BT_INTEGER, di, REQUIRED, x, BT_REAL, dd, REQUIRED);
add_sym_3 ("bessel_jn", GFC_ISYM_JN2, CLASS_TRANSFORMATIONAL, ACTUAL_NO,
BT_REAL, dr, GFC_STD_F2008,
gfc_check_bessel_n2, gfc_simplify_bessel_jn2,
gfc_resolve_bessel_n2,
"n1", BT_INTEGER, di, REQUIRED,"n2", BT_INTEGER, di, REQUIRED,
x, BT_REAL, dr, REQUIRED);
set_attr_value (3, true, true, true);
make_generic ("bessel_jn", GFC_ISYM_JN, GFC_STD_F2008);
I don't see how bessel_jn can be made an alias to besjn (an entity with
2 args), and then a few lines later it is defined with 3 args and made
generic? I think besjn and bessel_jn need to be dealt with separately
with "n2" in bessel_jn set as OPTIONAL.
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #5 from Markus Trippelsdorf --- Not a dup according to Jason. Reopening.
[Bug target/53854] ICE in find_constant_pool_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854 --- Comment #8 from Dan Horák --- for the record - ICE still present in gcc version 4.9.1 20140813 (Red Hat 4.9.1-7) (GCC)
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624
--- Comment #8 from Jason Merrill ---
(In reply to Markus Trippelsdorf from comment #7)
> static __typeof 0 a __attribute__ ((__weakref__ ("")));
> template class A
> {
> static __thread int b;
> };
The problem with this testcase is that set_decl_tls_model adds A::b, an
uninstantiated template, to the symbol table. This ICE was introduced by
honza's r211689.
I'll deal with the other testcase.
[Bug c++/62271] 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62271 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-26 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- Please provide preprocessed testcase and the complete command line that triggers the bug (see https://gcc.gnu.org/bugs/).
[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188 --- Comment #10 from Steve Kargl --- On Tue, Aug 26, 2014 at 07:51:45AM -0700, Steve Kargl wrote: > On Tue, Aug 26, 2014 at 01:08:22PM +, burnus at gcc dot gnu.org wrote: > > > > Steve, should we also add a test case for the "n1 < 0"? > > > Checking in general looks broken for bessel_yn and probably _jn. program neumann_test implicit none integer n1, n2 real x, b(10) x = 42. b = bessel_yn(-5, x) n1 = -5 n2 = 5 b = bessel_yn(n1, n2, x) ! b = bessel_yn(-5, n2, x) end program neumann_test troutmask:sgk[223] gfc5x -o z bes.f90 troutmask:sgk[224] gfc5x -o z -std=f2008 bes.f90 bes.f90:8.17: b = bessel_yn(-5, x) 1 Error: GNU Extension: Negative argument N at (1) First, this GNU Extension should not exists as bessel_[jy]n are new in F2008 and I think we should adhere to the standard. Second, umcommenting he last line in the program yields bes.f90:12.7: b = bessel_yn(-5, n2, x) 1 Error: Too many arguments in call to 'bessel_yn' at (1) So, it appears the wrong checking function is getting called. It may take me a day or 2 to unravel the issue.
[Bug c++/62271] 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62271 --- Comment #1 from loic.b...@unix-experience.fr --- Precisions on the platform: Archlinux x86_64 with 3.16.1-1-ARCH #1 SMP PREEMPT gcc-multilib 4.9.1-1
[Bug c++/62271] New: 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62271 Bug ID: 62271 Summary: 4.9 Regression: in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1449 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: loic.b...@unix-experience.fr Today i experience a bug when compiling dolphin-emulator. A static table cannot compile when m_CachedFRegs[i][1] is called. The table is declared like this: m_CachedFRegs[32][2] When i increase to m_CachedFRegs[32][3] compilation pass. Else i have this error: Building CXX object Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/Debugger/RegisterView.cpp.o /home/nerzhul/Devel/dolphin/Source/Core/DolphinWX/Debugger/RegisterView.cpp: In member function ‘virtual void CRegisterView::Update()’: /home/nerzhul/Devel/dolphin/Source/Core/DolphinWX/Debugger/RegisterView.cpp:186:6: erreur interne du compilateur: dans vect_get_vec_def_for_operand, à tree-vect-stmts.c:1449 void CRegisterView::Update() ^ Please submit a full bug report, with preprocessed source if appropriate. See https://bugs.archlinux.org/ for instructions. Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/build.make:560: recipe for target 'Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/Debugger/RegisterView.cpp.o' failed make[2]: *** [Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/Debugger/RegisterView.cpp.o] Error 1 CMakeFiles/Makefile2:679: recipe for target 'Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/all' failed make[1]: *** [Source/Core/DolphinWX/CMakeFiles/dolphin-emu.dir/all] Error 2 Makefile:147: recipe for target 'all' failed make: *** [all] Error 2 It's similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60896 Thanks !
[Bug fortran/62270] -Wlogical-not-parentheses warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270 --- Comment #1 from Marek Polacek --- You can see these errors if you try to bootstrap gcc with this patch: diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt index d619250..d84b9fe 100644 --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -519,7 +519,7 @@ C ObjC C++ ObjC++ Var(warn_logical_op) Init(0) Warning Warn when a logical operator is suspiciously always evaluating to true or false Wlogical-not-parentheses -C ObjC C++ ObjC++ Var(warn_logical_not_paren) Warning +C ObjC C++ ObjC++ Var(warn_logical_not_paren) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall) Warn when logical not is used on the left hand side operand of a comparison Wlong-long
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Jack Howarth changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #28 from Jack Howarth --- I noticed that MacPorts is using… #if SANITIZER_MAC && ( !defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T) and # if ! defined(__DARWIN_64_BIT_INO_T) || __DARWIN_64_BIT_INO_T rather than just… #if SANITIZER_MAC && __DARWIN_64_BIT_INO_T and # if __DARWIN_64_BIT_INO_T in their patch for gcc49… https://trac.macports.org/browser/trunk/dports/lang/gcc49/files/patch-10.10.diff Should we be doing the same?
[Bug fortran/62270] New: -Wlogical-not-parentheses warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62270 Bug ID: 62270 Summary: -Wlogical-not-parentheses warnings Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org -Wlogical-not-parentheses detected these two issues: interface.c:compare_parameter 2013 /* F2008, 12.5.2.5; IR F08/0073. */ 2014 if (formal->ts.type == BT_CLASS && formal->attr.class_ok 2015 && actual->expr_type != EXPR_NULL 2016 && ((CLASS_DATA (formal)->attr.class_pointer 2017&& !formal->attr.intent == INTENT_IN) trans-expr.c:gfc_conv_procedure_call 4445 if (fsym->attr.optional 4446 && e->expr_type == EXPR_VARIABLE 4447 && (!e->ref 4448 || (e->ref->type == REF_ARRAY 4449 && !e->ref->u.ar.type != AR_FULL)) But my attempts to fix these failed. The first one should likely be "&& formal->attr.intent != INTENT_IN)", but that regressed gfortran.dg/pointer_intent_7.f90 test. If I change it to "==", many tests fail. For the second one, perhaps just the "!" should be dropped, but I'm not sure about that, testsuite didn't reveal anything. Currently this PR is the last thing that is blocking the inclusion of -Wlogical-not-parentheses in -Wall - I'd appreciate if anyone could look into this PR.
[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62263
--- Comment #6 from M.E. O'Neill ---
(In reply to Marek Polacek from comment #3)
> We handle at least
> (x << n) | (x >> ((-n) & 31))
> (N can be 0 here) since PR57157.
Although this code does work with LLVM, testing with GCC 4.9.0, and this
implementation
unsigned int rotl32_doubleand4(unsigned int v, unsigned char r)
{
return (v << (r & 31)) | (v >> ((-r) & 31));
}
(or variations with r being a char or int) produces code like this:
_rotl32_doubleand4:
LFB6:
movl%esi, %ecx
movl%edi, %eax
negl%ecx
shrl%cl, %eax
movl%esi, %ecx
sall%cl, %edi
orl%edi, %eax
ret
... so it failed to spot the idiom entirely.
[Bug target/61330] [5 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Joseph S. Myers --- Fixed for GCC 5.
[Bug target/60606] [ARM] ICE with asm ("mov ...", pc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606 Joseph S. Myers changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #8 from Joseph S. Myers --- Fixed (making this a normal error) for GCC 5.
[Bug target/61330] [5 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330
--- Comment #7 from Joseph S. Myers ---
Author: jsm28
Date: Tue Aug 26 17:06:31 2014
New Revision: 214526
URL: https://gcc.gnu.org/viewcvs?rev=214526&root=gcc&view=rev
Log:
Fix ARM ICE for register var asm ("pc") (PR target/60606).
PR target/60606
PR target/61330
* varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and
DECL_HARD_REGISTER and return for invalid register specifications.
* cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears
DECL_HARD_REGISTER, call expand_one_error_var.
* config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow
CC_REGNUM with non-MODE_CC modes.
(arm_regno_class): Return NO_REGS for PC_REGNUM.
testsuite:
* gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c,
gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests.
Added:
trunk/gcc/testsuite/gcc.dg/torture/pr60606-1.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-2.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-3.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c
[Bug target/60606] [ARM] ICE with asm ("mov ...", pc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60606
--- Comment #7 from Joseph S. Myers ---
Author: jsm28
Date: Tue Aug 26 17:06:31 2014
New Revision: 214526
URL: https://gcc.gnu.org/viewcvs?rev=214526&root=gcc&view=rev
Log:
Fix ARM ICE for register var asm ("pc") (PR target/60606).
PR target/60606
PR target/61330
* varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and
DECL_HARD_REGISTER and return for invalid register specifications.
* cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears
DECL_HARD_REGISTER, call expand_one_error_var.
* config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow
CC_REGNUM with non-MODE_CC modes.
(arm_regno_class): Return NO_REGS for PC_REGNUM.
testsuite:
* gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c,
gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests.
Added:
trunk/gcc/testsuite/gcc.dg/torture/pr60606-1.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-2.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-3.c
trunk/gcc/testsuite/gcc.target/arm/pr60606-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c
[Bug target/61610] [5 Regression] ICE in assign_by_spills, at lra-assigns.c:1335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61610 --- Comment #3 from Joel Sherrill --- For the preprocessed newlib strtod source, -O2 will reproduce. Dropping -EL or to -O1 results in it compiling. /users/joel/test-gcc/b-mips-rtems4.11-gcc/./gcc/xgcc -B/users/joel/test-gcc/b-mips-rtems4.11-gcc/./gcc/ -c -EL -O2 -mips3 newlib_strtod_preprocessed.c
[Bug target/61610] [5 Regression] ICE in assign_by_spills, at lra-assigns.c:1335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61610 Joel Sherrill changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #2 from Joel Sherrill --- Created attachment 33398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33398&action=edit Preprocessed newlib strtod.c source to reproduce issue This is the newlib example to reproduce this.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #27 from James Clarke --- Updated patches: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02415.html
[Bug target/45360] arm: -mhard-float != -mfloat-abi=hard during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45360 Yvan Roux changed: What|Removed |Added CC||yvan.roux at linaro dot org --- Comment #3 from Yvan Roux --- This is fixed on trunk, and I guess since Joseph's commit on 4.7. Do we need to check that to close the PR ?
[Bug libgcc/62269] New: m32c-elf libgcc fails to configure- setjmp/longjmp exception check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62269 Bug ID: 62269 Summary: m32c-elf libgcc fails to configure- setjmp/longjmp exception check Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: joel at gcc dot gnu.org configure: WARNING: decimal float is not supported for this target, ignored checking whether fixed-point is supported... no checking whether to use setjmp/longjmp exceptions... unknown configure: error: unable to detect exception model make[1]: *** [configure-target-libgcc] Error 1 Since the m32c doesn't support C++, I am wondering if this configure check is over simplified.
[Bug target/55928] m32c ICE building libgcc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55928 Joel Sherrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Joel Sherrill --- The RTEMS Community is using the following version for the m32c so this must have been resolved. ~/rtems-4.11-work/tools/bin/m32c-rtems4.11-gcc --version m32c-rtems4.11-gcc (GCC) 4.8.3 20140522 (RTEMS 4.11-RSB-257d1e4378c80968de57ba888e235888adb0e992-modified-1,gcc-4.8.3/newlib-19-Aug-2014)
[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188 --- Comment #9 from Steve Kargl --- On Tue, Aug 26, 2014 at 01:08:22PM +, burnus at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188 > > Tobias Burnus changed: > >What|Removed |Added > > CC||burnus at gcc dot gnu.org > > --- Comment #8 from Tobias Burnus --- > (In reply to kargl from comment #7) > > > Actually, no. We inspected the function manually looking for the > > > cause of a test FAIL of bessel_7.f90 and just stumbled across it. > > Which would be: > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02311.html > > > Committed to trunk and all open branches. > > Steve, should we also add a test case for the "n1 < 0"? > I only looked at the specific issue raised by OP. If calling bessel_yn() with n1 < 0 violates requirements of the standard, then yes we should probably check for that situation. I'll cast an eye over this later today.
[Bug bootstrap/62260] Build inside source tree doesn't work with lto-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62260 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from H.J. Lu --- Fixed.
[Bug bootstrap/62260] Build inside source tree doesn't work with lto-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62260 --- Comment #2 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 26 14:47:15 2014 New Revision: 214524 URL: https://gcc.gnu.org/viewcvs?rev=214524&root=gcc&view=rev Log: Properly set gcc_build_dir for in-tree build PR bootstrap/62260 * Makefile.am (gcc_build_dir): Set to @gcc_build_dir@. * configure.ac (gcc_build_dir): Set and AC_SUBST according to $host_subdir. * Makefile.in: Regenerated. * configure: Likewise. Modified: trunk/lto-plugin/ChangeLog trunk/lto-plugin/Makefile.am trunk/lto-plugin/Makefile.in trunk/lto-plugin/configure trunk/lto-plugin/configure.ac
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #18 from Marek Polacek --- Author: mpolacek Date: Tue Aug 26 14:24:15 2014 New Revision: 214523 URL: https://gcc.gnu.org/viewcvs?rev=214523&root=gcc&view=rev Log: PR c/61271 * sel-sched-ir.c (make_regions_from_the_rest): Fix condition. Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c
[Bug target/62128] Use vpalignr for AVX2 rotation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62128 --- Comment #2 from Stupachenko Evgeny --- The patch fixing this submitted for review. Code generated when patch applied: vperm2i128 $33, %ymm0, %ymm0, %ymm1 vpalignr$1, %ymm0, %ymm1, %ymm1 vmovdqa %ymm1, %ymm0
[Bug c++/62255] Introducing an unrelated template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255 Max Gerlach changed: What|Removed |Added Known to work||4.7.3 --- Comment #5 from Max Gerlach --- gcc 4.7.3 compiles the code without errors. $ g++-4.7 --version g++-4.7 (Ubuntu/Linaro 4.7.3-12ubuntu1) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #213 from Steffen Hau --- Hi Jan, just a short Update: Firefox since version 30 as well as Thunderbird since version 31 both compile fine with LTO enabled without the need of any additional patches. The package size was reduced by 51% (firefox ~420MB -> ~207MB) and 59% (thunderbird ~480MB -> ~200MB). Both programs work as intended, no crashes or unexpected behaviour so far. Best regards, Steffen
[Bug libfortran/62188] Array bounds overrun in bessel_yn_r4/8/16 and other functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62188 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Tobias Burnus --- (In reply to kargl from comment #7) > > Actually, no. We inspected the function manually looking for the > > cause of a test FAIL of bessel_7.f90 and just stumbled across it. Which would be: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02311.html > Committed to trunk and all open branches. Steve, should we also add a test case for the "n1 < 0"?
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #7 from Markus Trippelsdorf ---
For 5:
markus@x4 tmp % cat boo.ii
static __typeof 0 a __attribute__ ((__weakref__ ("")));
template class A
{
static __thread int b;
};
markus@x4 tmp % g++ -std=c++11 boo.ii
boo.ii:5:2: internal compiler error: Segmentation fault
};
^
0xbbfe5f crash_signal
../../gcc/gcc/toplev.c:339
0x856964 tree_check
../../gcc/gcc/tree.h:2962
0x856964 symbol_table::decl_assembler_name_hash(tree_node const*)
../../gcc/gcc/symtab.c:69
0x856c13 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/gcc/symtab.c:181
0x856d5c symbol_table::symtab_initialize_asm_name_hash()
../../gcc/gcc/symtab.c:263
0x858414 symbol_table::symtab_initialize_asm_name_hash()
../../gcc/gcc/symtab.c:958
0x858414 symtab_node::get_for_asmname(tree_node const*)
../../gcc/gcc/symtab.c:947
0x864d80 handle_alias_pairs
../../gcc/gcc/cgraphunit.c:
0x869d8c symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2264
0x656d6a cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4666
Please submit a full bug report,
with preprocessed source if appropriate.
for 4.8, 4.9 and 5:
markus@x4 tmp % cat test.ii
namespace std
{
typedef int string;
template class unique_ptr;
}
template class A
{
static thread_local std::unique_ptr s;
public:
A () { s; }
};
int main () { A a; }
markus@x4 tmp % g++ -std=c++11 test.ii
cc1plus: internal compiler error: Segmentation fault
0xbbfe5f crash_signal
../../gcc/gcc/toplev.c:339
0x856964 tree_check
../../gcc/gcc/tree.h:2962
0x856964 symbol_table::decl_assembler_name_hash(tree_node const*)
../../gcc/gcc/symtab.c:69
0x856c13 symbol_table::insert_to_assembler_name_hash(symtab_node*, bool)
../../gcc/gcc/symtab.c:181
0x856d5c symbol_table::symtab_initialize_asm_name_hash()
../../gcc/gcc/symtab.c:263
0x8699d2 analyze_functions
../../gcc/gcc/cgraphunit.c:1094
0x869da5 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2277
0x656d6a cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4666
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62263 --- Comment #5 from Marc Glisse --- Also, I would have expected the pattern *3_mask to avoid generating 'andl' before 'roll'.
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Known to fail|4.10.0 |5.0 --- Comment #4 from Markus Trippelsdorf --- dup *** This bug has been marked as a duplicate of bug 58624 ***
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624 Markus Trippelsdorf changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #6 from Markus Trippelsdorf --- *** Bug 61558 has been marked as a duplicate of this bug. ***
[Bug middle-end/58624] gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58624 Markus Trippelsdorf changed: What|Removed |Added CC||stefan at schweter dot it --- Comment #5 from Markus Trippelsdorf --- *** Bug 62268 has been marked as a duplicate of this bug. ***
[Bug c++/62268] ICE: segmentation fault with Boost.Asio 1.55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62268 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- dup *** This bug has been marked as a duplicate of bug 58624 ***
[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62263 --- Comment #4 from Marc Glisse --- Problem here is conversions that happen in places where we don't handle them. A couple more patterns should do it (it could be a good test for the optional convert feature in the match branch). For the zerocheck version, it would work if r was an int, but here we get 2 insns in the branch (convert+rotate) which is quite a bit harder to handle than a single rotate insn.
[Bug c++/62268] New: ICE: segmentation fault with Boost.Asio 1.55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62268
Bug ID: 62268
Summary: ICE: segmentation fault with Boost.Asio 1.55
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stefan at schweter dot it
Hi,
I'm using GCC 5 (on Debian Testing):
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /usr/src/gcc/configure --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 5.0.0 20140826 (experimental) (GCC)
Boost version is 1.55.
When compiling this code with g++ -std=c++11 or g++ -lboost_system:
#include
int main()
{
return 0;
}
An ICE occurs:
test1.cpp:6:1: internal compiler error: Segmentation fault
}
^
Can anyone confirm this error?
Thanks in advance + regards,
Stefan
[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62263 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- We handle at least (x << n) | (x >> ((-n) & 31)) (N can be 0 here) since PR57157.
[Bug gcov-profile/62267] disable fprofile-use at coverage-mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62267 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- 5) Fix the libreoffice build system and make it deterministic.
[Bug libstdc++/62264] std::experimental::string_view won't compile with -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62264 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #3 from Jonathan Wakely --- Fixed for 4.9.2
[Bug libstdc++/62264] std::experimental::string_view won't compile with -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62264 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Tue Aug 26 11:23:21 2014 New Revision: 214500 URL: https://gcc.gnu.org/viewcvs?rev=214500&root=gcc&view=rev Log: PR libstdc++/62264 * include/experimental/string_view: Fix inconsistent exception specs. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/experimental/string_view
[Bug gcov-profile/62267] New: disable fprofile-use at coverage-mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62267 Bug ID: 62267 Summary: disable fprofile-use at coverage-mismatch Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: ioctl at yandex dot ru I would like to suggest a new feature: Add an option to disable profile usage in case of profile missmatch. While rebuilding libreoffice 4.3.0 with profile data to make it work faster on my old CPU, I have noticed a lot of errors like this: the control flow of function «_ZNSt16allocator_traitsISaIPN5svgio9svgreader18SvgStyleAttributesEEE8allocateERS4_j» does not match its profile data (counter «time_profiler») [-Werror=coverage-mismatch] At that I clearly remember, that I have not changed source archive before rebuilding with profile usage. However, some files possibly generated with bison or flex may be changed. Now in this situation I have three choices: 1) Do not use profile data, that will decrease program speed. 2) Add option to treat this error as warning, so some modules will be "deoptimized". 3) Rebuild any such case manually without profile, that require a lot of time. I would like to suggest an option to make possible another choice: 4) Automatically disable profile usage in case of profile missmatch.
[Bug c++/62266] Loop unrolling with template metaprogramming not aggressive enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62266 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The program is not legal C++ and is required to be rejected, the template argument must be a constant expression.
[Bug target/62254] gcc-4.9 ICEs on linux kernel zlib for armv3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Summary|gcc-4.9 miscompiles linux |gcc-4.9 ICEs on linux |kernel zlib for armv3 |kernel zlib for armv3 --- Comment #2 from Richard Biener --- Not exactly "miscompile"
[Bug libstdc++/62256] /usr/include/c++/4.8/tr1/random.tcc:792:2: error: no matching function for call to 'min'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62256 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Richard Biener --- Thus wontfix.
[Bug ada/62117] [4.9 regression] wrong code for passing small array argument'Address, in generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62117 yuta tomino changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from yuta tomino --- Thank you for looking, Eric. Surely, as you say, memcmp is unsuitable for presenting an example. It's my mistake. But I had not found other case at the time. I found another case since then. Pure is not a trigger in this case. Please look this, too. In the new case, it uses Float'Valid attribute calling System.Fat_Flt.Unaligned_Valid implicitly. Unaligned_Valid takes an Address argument. But it's not marked as pure. And, it's a detail of compiler implementation. I think this behavior should not affect application code. It needs the type U for calling Unaligned_Valid. If this type is removed (and some other method like Unchecked_Conversion is used), System.Fat_Flt.Valid may be called instead of Unaligned_Valid. System.Fat_Flt.Valid works correctly. I apologize for taking your time. -- case2.ads package case2 is -- not pure package function Packed_Unaligned_Valid (Item : Long_Long_Integer) return Boolean; -- not pure function end case2; -- case2.adb with system.storage_elements; package body case2 is use type System.Storage_Elements.Storage_Offset; -- A Float value is packed into the argument Item, at unaligned position. type U is record C : Character; F : Float; end record; pragma Pack (U); function Packed_Unaligned_Valid (Item : Long_Long_Integer) return Boolean is X : U; for X'Address use Item'Address; begin return X.F'Valid; -- implicit calling System.Fat_Flt.Unaligned_Valid end Packed_Unaligned_Valid; end case2; gcc-4.9 _case2__packed_unaligned_valid: LFB3: subq$24, %rsp LCFI0: leaq9(%rsp), %rdi call_system__fat_flt__attr_float__unaligned_valid addq$24, %rsp LCFI1: ret === gcc-4.8 _case2__packed_unaligned_valid: LFB3: subq$24, %rsp LCFI0: movq%rdi, 8(%rsp) # this operation is missing in gcc-4.9 leaq9(%rsp), %rdi call_system__fat_flt__attr_float__unaligned_valid addq$24, %rsp LCFI1: ret
[Bug middle-end/62263] Good codegen for bitwise rotate requires code that is technically undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62263 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Richard Biener --- I believe we handle at least some "correct" forms now - Jakub?
[Bug c++/62266] New: Loop unrolling with template metaprogramming not aggressive enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62266
Bug ID: 62266
Summary: Loop unrolling with template metaprogramming not
aggressive enough
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cand at gmx dot com
The following code fails to compile with all GCC versions I have, up to g++
(GCC) 5.0.0 20140817 (experimental). It also fails with clang, but it would be
nice for this to work, as it would save some writing.
The index i is in constant bounds, and so the compiler should be able to fully
unroll this loop into "foo<0>(); foo<1>(); foo<2>();".
#include
template void foo() {
printf("%u\n", T);
}
int main() {
int i;
for (i = 0; i < 3; i++) {
foo();
}
return 0;
}
[Bug c++/62175] [4.9 Regression] Internal compiler error in gimplify_modify_expr gimplify.c:4616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62175 Richard Biener changed: What|Removed |Added Summary|[4.9/5 Regression] Internal |[4.9 Regression] Internal |compiler error in |compiler error in |gimplify_modify_expr|gimplify_modify_expr |gimplify.c:4616 |gimplify.c:4616 --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
[Bug rtl-optimization/62265] [4.8/4.9/5 regression] FAIL: gcc.dg/20111227-2.c scan-rtl-dump ree "Elimination opportunities = 3 realized = 3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62265 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.8.4 Summary|[4.8/4.9/5.0 regression]|[4.8/4.9/5 regression] |FAIL: gcc.dg/20111227-2.c |FAIL: gcc.dg/20111227-2.c |scan-rtl-dump ree |scan-rtl-dump ree |"Elimination opportunities |"Elimination opportunities |= 3 realized = 3" |= 3 realized = 3"
[Bug tree-optimization/62217] [4.9/5 Regression] DOM confuses complete unrolling which in turn causes VRP to warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62217 Richard Biener changed: What|Removed |Added Keywords||diagnostic, ||missed-optimization Known to work||4.8.3 Target Milestone|--- |4.9.2 Summary|DOM confuses complete |[4.9/5 Regression] DOM |unrolling which in turn |confuses complete unrolling |causes VRP to warn |which in turn causes VRP to ||warn
[Bug c++/62240] A using-declaration within a class can publish a public base of a private base.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62240
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-08-26
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Agreed, the attached code (repeated below) should be rejected.
class A {};
class B : public A {};
class C : B
{
public:
using B::A;
};
int main()
{
A *p = new C;
}
[Bug tree-optimization/62220] missed optimization wrt module for loop variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62220 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-26 CC||grosser at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Note that as the suggested transform is quite complicated (splitting the loop and completely changing iteration order) this is applicable for GRAPHITE and thus polly? Otherwise for more "simple" cases there is handling stuff similar to strength-reduction or to the tree-ssa-loop-im.c:rewrite_reciprocal/rewrite_bittest cases.
[Bug c++/62244] Function parameter should be in scope in its own default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62244 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-26 Ever confirmed|0 |1
[Bug libstdc++/62256] /usr/include/c++/4.8/tr1/random.tcc:792:2: error: no matching function for call to 'min'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62256 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-26 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This would fix it, but I'm not planning to commit it because I don't think anyone cares about TR1 in current versions of GCC: --- a/libstdc++-v3/include/tr1/random.tcc +++ b/libstdc++-v3/include/tr1/random.tcc @@ -789,11 +789,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION const int __w = std::numeric_limits::digits; const result_type __m1 = - std::min(result_type(_M_b1.max() - _M_b1.min()), + std::min(result_type(_M_b1.max() - _M_b1.min()), __detail::_Shift::__value - 1); const result_type __m2 = - std::min(result_type(_M_b2.max() - _M_b2.min()), + std::min(result_type(_M_b2.max() - _M_b2.min()), __detail::_Shift::__value - 1); // NB: In TR1 s1 is not required to be >= s2.
[Bug rtl-optimization/62208] [5 Regression] ICE with -fwhole-program on valid code at -O3 on x86_64-linux-gnu in trunc_int_for_mode, at explow.c:56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62208 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0 Summary|ICE with -fwhole-program on |[5 Regression] ICE with |valid code at -O3 on|-fwhole-program on valid |x86_64-linux-gnu in |code at -O3 on |trunc_int_for_mode, at |x86_64-linux-gnu in |explow.c:56 |trunc_int_for_mode, at ||explow.c:56
[Bug rtl-optimization/62208] ICE with -fwhole-program on valid code at -O3 on x86_64-linux-gnu in trunc_int_for_mode, at explow.c:56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62208 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-26 CC||rsandifo at gcc dot gnu.org Summary|ICE with LTO on valid code |ICE with -fwhole-program on |at -O3 on x86_64-linux-gnu |valid code at -O3 on |in trunc_int_for_mode, at |x86_64-linux-gnu in |explow.c:56 |trunc_int_for_mode, at ||explow.c:56 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- As it's a single file, does it reproduce with -fwhole-program instead of -flto? Still can't reproduce in my dev tree (but as usual this may have too many patches...). Confirmed on match-and-simplify branch with -fwhole-program. Needs -march=x86-64 as well. 55/* You want to truncate to a _what_? */ 56gcc_assert (SCALAR_INT_MODE_P (mode)); (gdb) p mode $1 = V4SImode #4 0x00c1683e in simplify_const_unary_operation (code=NOT, mode=V4SImode, op=0x766ca470, op_mode=V4SImode) at /space/rguenther/src/svn/match-and-simplify/gcc/simplify-rtx.c:1735 1735 return immed_wide_int_const (result, mode); Likely caused by the wide-int merge. Richard?
[Bug c++/62224] [4.9 Regression] Possible regression in gcc-4.9-20140820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62224 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.9.2 Summary|Possible regression in |[4.9 Regression] Possible |gcc-4.9-20140820|regression in ||gcc-4.9-20140820 --- Comment #2 from Richard Biener --- Raising to P1 to be on the radar for the 4.9.2 release. _Not_ confirmed yet. I hope the preprocessed source file is that providing the functions the unresolved references look for.
[Bug testsuite/62234] warnings/errors from LTO cannot be tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62234 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-26 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/62238] [4.9/5 Regression] ICE with LTO on valid code on x86_64-linux-gnu in verify_ssa (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62238 Richard Biener changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-26 Target Milestone|--- |4.9.2 Summary|ICE with LTO on valid code |[4.9/5 Regression] ICE with |on x86_64-linux-gnu in |LTO on valid code on |verify_ssa (in 64-bit mode) |x86_64-linux-gnu in ||verify_ssa (in 64-bit mode) Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed, triggered by predictive commoning.
[Bug lto/62239] [5 Regression] ICE: in execute_todo, at passes.c:1795 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62239 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-26 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Mine.
[Bug libstdc++/62264] std::experimental::string_view won't compile with -pedantic-errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62264 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-26 Known to work||5.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I already fixed this on the trunk, I'll backport it to the 4.9 branch.
[Bug c++/61825] [5 regression] g++.dg/cpp0x/static_assert9.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61825 Dominique d'Humieres changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres --- Also seen on *86*-*-*. From https://gcc.gnu.org/ml/gcc-regression/2014-07/msg00218.html the test has started to fail at revision r212499.
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #17 from Marek Polacek --- Author: mpolacek Date: Tue Aug 26 09:35:10 2014 New Revision: 214496 URL: https://gcc.gnu.org/viewcvs?rev=214496&root=gcc&view=rev Log: PR c/61271 * expr.c (is_aligning_offset): Remove logical not. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug c++/62255] Introducing an unrelated template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255 --- Comment #4 from Max Gerlach --- The bug is still present on g++ 4.9.1. $ g++-4.9 --version g++-4.9 (Ubuntu 4.9.1-3ubuntu2~14.04.1) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Output of $ g++-4.9 -c arma_template_test.cpp -Wall -Wextra -std=c++11 &> output-4.9.1.txt has been attached.
[Bug c++/62255] Introducing an unrelated template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255 --- Comment #3 from Max Gerlach --- Created attachment 33397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33397&action=edit Compiler error messages from g++ 4.9.1
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #16 from Marek Polacek --- Author: mpolacek Date: Tue Aug 26 09:30:29 2014 New Revision: 214495 URL: https://gcc.gnu.org/viewcvs?rev=214495&root=gcc&view=rev Log: PR c/61271 * tree-vectorizer.h (LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT, LOOP_REQUIRES_VERSIONING_FOR_ALIAS): Wrap in parens. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/tree-vectorizer.h
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #15 from Marek Polacek --- Author: mpolacek Date: Tue Aug 26 09:25:37 2014 New Revision: 214494 URL: https://gcc.gnu.org/viewcvs?rev=214494&root=gcc&view=rev Log: PR c/61271 * tree-vectorizer.h (LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT, LOOP_REQUIRES_VERSIONING_FOR_ALIAS): Wrap in parens. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-vectorizer.h
[Bug c/61271] 10 * possible coding error with logical not (!)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61271 --- Comment #14 from Marek Polacek --- Author: mpolacek Date: Tue Aug 26 09:21:18 2014 New Revision: 214493 URL: https://gcc.gnu.org/viewcvs?rev=214493&root=gcc&view=rev Log: PR c/61271 * tree-vectorizer.h (LOOP_REQUIRES_VERSIONING_FOR_ALIGNMENT, LOOP_REQUIRES_VERSIONING_FOR_ALIAS): Wrap in parens. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vectorizer.h
