[Bug bootstrap/61763] [4.9 Regression] gcc-4.9.0 "Bootstrap comparison failure!"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763 --- Comment #4 from Douglas Mencken --- (In reply to Jakub Jelinek from comment #3) > GCC 4.9.1 has been released. With 4.9.1 release I got: ... rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/gengtype.o differs make[2]: *** [compare] Error 1 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2
[Bug libstdc++/60936] [4.9 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #4 from Jonathan Wakely --- The __throw_range_error_fmt function added to basic_string::at() depends on locales. We could avoid that dependency when the library is configured with --disable-libstdcxx-verbose
[Bug libstdc++/60936] [4.9 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #5 from Jonathan Wakely --- Alternatively, we could just move the __int_to_char instantiations to a separate file from the locale facets.
[Bug c++/61850] New: g++ crashes (SEGV) on the following endless template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61850
Bug ID: 61850
Summary: g++ crashes (SEGV) on the following endless template
instantiation
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: akim.demaille at gmail dot com
Hi,
I'm toying with templates and enable_if to try to enforce commutativity on some
operator. In the course of these experiments, I fell on the following crash.
I have not tried to scale it down, sorry about that. I know my program is
wrong. Maybe eventually I will spend some time to make it smaller, but maybe
that's already good for you.
Cheers.
#include
template
struct join_impl
{
enum { forward = true };
};
/// T without reference or const/volatile qualifiers.
template
using base_t
= typename std::remove_cv::type>::type;
template
typename join_impl, base_t>::type
join(V1 v1, V2 v2)
{
return join_impl, base_t>::join(v1, v2);
}
template
struct join_impl
{
enum { forward = false };
using type = T;
static type join(type v1, type v2) { return v1 * v2; }
};
template
struct join_impl::forward>::type>
{
enum { forward = false };
using super = join_impl;
using type = typename super::type;
static
type
join(T1 v1, T2 v2)
{
return super::join(v2, v1);
}
};
int main()
{
int i = 20;
float f = 0.1;
#define ECHO(S) std::cerr << #S": " << S << '\n'
// ECHO(::join(i, i));
ECHO(::join(i, f));
ECHO(::join(f, i));
ECHO(::join(f, f));
}
g++-mp-4.9 -Wall -std=c++11 v4-without-wrapper.cc
g++-mp-4.9: error: v4-without-wrapper.cc: No such file or directory
g++-mp-4.9: fatal error: no input files
compilation terminated.
g++-mp-4.9 (MacPorts gcc49 4.9-20140416_2) 4.9.0 20140416 (prerelease)
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 fortran/61780] [4.8/4.9 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 --- Comment #7 from Paul Thomas --- Author: pault Date: Sat Jul 19 13:49:40 2014 New Revision: 212846 URL: https://gcc.gnu.org/viewcvs?rev=212846&root=gcc&view=rev Log: 2014-07-19 Paul Thomas PR fortran/61780 * dependency.c (gfc_dep_resolver): Index the 'reverse' array so that elements are skipped. This then correctly aligns 'reverse' with the scalarizer loops. 2014-07-19 Paul Thomas PR fortran/61780 * gfortran.dg/dependency_44.f90 : New test Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/dependency_44.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/dependency.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/61780] [4.8/4.9 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 --- Comment #8 from Paul Thomas --- Author: pault Date: Sat Jul 19 14:31:06 2014 New Revision: 212847 URL: https://gcc.gnu.org/viewcvs?rev=212847&root=gcc&view=rev Log: 2014-07-19 Paul Thomas PR fortran/61780 * dependency.c (gfc_dep_resolver): Index the 'reverse' array so that elements are skipped. This then correctly aligns 'reverse' with the scalarizer loops. 2014-07-19 Paul Thomas PR fortran/61780 * gfortran.dg/dependency_44.f90 : New test Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/dependency_44.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/dependency.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/61780] [4.8/4.9 Regression] Wrong code when shifting elements of a multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61780 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on 4.8, 4.9 and trunk. Thanks for the report Paul
[Bug c++/61851] New: Compiling litecoin results in internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61851 Bug ID: 61851 Summary: Compiling litecoin results in internal compile error Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: paul.thomas-0o0qzl3o at yopmail dot com g++ -c -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -D_FILE_OFFSET_BITS=64 -I/home/paul/src/litecoin/src -I/home/paul/src/litecoin/src/obj -DUSE_UPNP=0 -DUSE_IPV6=1 -I/home/paul/src/litecoin/src/leveldb/include -I/home/paul/src/litecoin/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -MMD -MF obj/alert.d -o obj/alert.o alert.cpp g++: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. make: *** [obj/alert.o] Error 4 This error popped up while trying to compile latest litecoin git using Debian/Wheezy with 128MB of RAM.
[Bug c++/54706] -fsyntax-only suppresses a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54706 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-19 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #5 from Paolo Carlini --- Looks like it makes sense to instantiate in GCC too.
[Bug c++/61851] Compiling litecoin results in internal compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61851 --- Comment #1 from Mikael Pettersson --- You ran out of RAM. Add some swap.
[Bug rtl-optimization/61461] -fdump-rtl-all-slim causes ICE with fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61461 Bernd Edlinger changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Bernd Edlinger --- fixed on trunk.
[Bug c/61852] New: Incorrect column number for -Wimplicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61852
Bug ID: 61852
Summary: Incorrect column number for
-Wimplicit-function-declaration
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
The current version points to the start of the statement containing the
undeclared function call.
$: cat t.c
int f (int a) {
int b = a + a + a + ff(a);
return b;
}
$: gcc-trunk -Wimplicit-function-declaration -c t.c
t.c: In function ‘f’:
t.c:2:3: warning: implicit declaration of function ‘ff’
[-Wimplicit-function-declaration]
int b = a + a + a + ff(a);
^
$: clang-trunk -Wimplicit-function-declaration -c t.c
t.c:2:23: warning: implicit declaration of function 'ff' is invalid in C99
[-Wimplicit-function-declaration]
int b = a + a + a + ff(a);
^
1 warning generated.
[Bug middle-end/61853] New: [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 Bug ID: 61853 Summary: [4.9,4.10 Regression] ICE: SIGSEGV in store_field Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu (gdb) r Starting program: /home/dave/gnu/gcc/objdir/stage1-gcc/cc1plus -fpreprocessed ConstituentParticleData.ii -quiet -dumpbase ConstituentParticleData.cc -auxbase-strip .libs/ConstituentParticleData.o -g -O2 -Wpedantic -Wall -Wextra -Wformat=1 -Werror=format-security -ansi -version -fPIC -o ConstituentParticleData.s GNU C++ (GCC) version 4.10.0 20140717 (experimental) [trunk revision 212770] (hppa-linux-gnu) compiled by GNU C version 4.9.0, GMP version 6.0.0, MPFR version 3.1.2-p3, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.10.0 20140717 (experimental) [trunk revision 212770] (hppa-linux-gnu) compiled by GNU C version 4.9.0, GMP version 6.0.0, MPFR version 3.1.2-p3, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 03431aebbd62606890d51bba87e8825f Program received signal SIGSEGV, Segmentation fault. 0x00a5870c in store_field (target=0xf7275af0, bitsize=64, bitpos=0, bitregion_start=0, bitregion_end=63, mode=DFmode, exp=0xf6f412d0, alias_set=7, nontemporal=) at ../../gcc/gcc/expr.c:6493 6493 && MEM_ALIGN (target) < GET_MODE_ALIGNMENT (mode)) (gdb) p debug_rtx (target) (parallel:BLK [ (expr_list:REG_DEP_TRUE (reg:DI 101 [ ]) (const_int 0 [0])) ]) $1 = void Maybe one can't store into a BLKmode structure? ICE doesn't occur with 4.8.
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 --- Comment #1 from John David Anglin --- Created attachment 33157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33157&action=edit Preprocessed source
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-19 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- > (gdb) p debug_rtx (target) > (parallel:BLK [ > (expr_list:REG_DEP_TRUE (reg:DI 101 [ ]) > (const_int 0 [0])) > ]) > $1 = void > > Maybe one can't store into a BLKmode structure? Not sure what you mean exactly but store_field shouldn't have been invoked on a PARALLEL so the problem is very likely up in the call chain.
[Bug c/61852] Incorrect column number for -Wimplicit-function-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61852 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-19 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine.
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 --- Comment #3 from dave.anglin at bell dot net --- On 19-Jul-14, at 5:39 PM, ebotcazou at gcc dot gnu.org wrote: > Not sure what you mean exactly but store_field shouldn't have been > invoked on a > PARALLEL so the problem is very likely up in the call chain. I'll take a look. -- John David Anglindave.ang...@bell.net
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 --- Comment #4 from John David Anglin --- store_field is called at expr.c:4955 on trunk.
[Bug c++/61838] ICE on Windows with ctors defined outside class definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61838
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #1 from Harald van Dijk ---
Not specific to Windows. On x86_64-pc-linux-gnu, both 4.9.1 and master as of
today ICE. It works from 4.4 to 4.8.
cc1plus: internal compiler error: Segmentation fault
0xbbc02f crash_signal
../../gcc/gcc/toplev.c:337
0x880df5 analyze_functions
../../gcc/gcc/cgraphunit.c:1054
0x88273f finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2338
0x671c70 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4684
/* If decl is a clone of an abstract function,
mark that abstract function so that we don't release its body.
The DECL_INITIAL() of that abstract function declaration
will be later needed to output debug info. */
if (DECL_ABSTRACT_ORIGIN (decl))
{
struct cgraph_node *origin_node
= cgraph_get_node (DECL_ABSTRACT_ORIGIN (decl));
1054 origin_node->used_as_abstract_origin = true;
}
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853
--- Comment #5 from John David Anglin ---
These are arguments to expand_assignment:
(gdb) p debug_tree(to)
unit size
align 64 symtab -85994080 alias set 8 canonical type 0xfad06ba0
precision 64
pointer_to_this reference_to_this
>
arg 0
public unsigned SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0xf9a44540>
arg 0
used ignored regdecl DF file ConstituentParticleData.h line 57 col
18 size unit size
align 64 context
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 101 [ ])
(const_int 0 [0]))
])>>
arg 1 constant 0>>
$1 = void
(gdb) p debug_tree(from)
unit size
align 64 symtab -85994080 alias set 8 canonical type 0xfad06ba0
precision 64
pointer_to_this reference_to_this
>
visited var def_stmt SR.222_7 = MEM[(const
struct ConstituentParticleData *)_2 + 8B];
version 7>
$2 = void
public:
/**
* Return the constituent mass of this parton.
*/
virtual Energy constituentMass() const { return theConstituentMass; }
[Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61853 --- Comment #6 from Eric Botcazou --- > arg 0 Energy> > used ignored regdecl DF file ConstituentParticleData.h line 57 > col 18 size unit size > align 64 context _ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv> > (parallel:BLK [ > (expr_list:REG_DEP_TRUE (reg:DI 101 [ ]) > (const_int 0 [0])) > ])>> Why is the DECL_MODE of the result DFmode while its DECL_RTL has BLKmode? What's the mode of the record type?
[Bug c/61854] New: Warning single-line comment for -std=c89?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61854
Bug ID: 61854
Summary: Warning single-line comment for -std=c89?
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Currently there is no warning on single-line comments for -std=c89. For
example, when I am compiling the following code extracted from SPEC, GCC emits
several errors and Clang emits a warning saying that the single-line comment is
not supported in the c89 language. IMHO, it is worth considering to emit such a
warning, as it is the root cause of the errors, making it easier to understand
the errors.
$: cat t.c
#include
void
_E_pr_info_header(char const *f, long ln, char const *msg)
{
//SPEC lots of informationals are printed for validation; use stdout
// intead of stderr so as to prefer buffered io
/* make different format so as not to be parsed by emacs compile */
(void) fprintf(stdout, "%s: %s(%ld): ", msg, f, ln);
}
$: gcc-trunk -c -pedantic -Wall -Wextra -std=c89 t.c
t.c: In function ‘_E_pr_info_header’:
t.c:6:3: error: expected expression before ‘/’ token
//SPEC lots of informationals are printed for validation; use stdout
^
t.c:6:61: error: unknown type name ‘use’
//SPEC lots of informationals are printed for validation; use stdout
^
t.c:7:3: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘/’
token
// intead of stderr so as to prefer buffered io
^
t.c:6:61: warning: ISO C90 forbids mixed declarations and code [-Wpedantic]
//SPEC lots of informationals are printed for validation; use stdout
^
t.c:4:31: warning: unused parameter ‘f’ [-Wunused-parameter]
_E_pr_info_header(char const *f, long ln, char const *msg)
^
t.c:4:39: warning: unused parameter ‘ln’ [-Wunused-parameter]
_E_pr_info_header(char const *f, long ln, char const *msg)
^
t.c:4:55: warning: unused parameter ‘msg’ [-Wunused-parameter]
_E_pr_info_header(char const *f, long ln, char const *msg)
^
$: clang-trunk -c -pedantic -Wcomment -std=c89 t.c
t.c:6:3: warning: // comments are not allowed in this language [-Wcomment]
//SPEC lots of informationals are printed for validation; use stdout
^
1 warning generated.
[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538 --- Comment #16 from Joshua Kinard --- (In reply to Andrew Pinski from comment #15) > (In reply to Joshua Kinard from comment #14) > > (In reply to Andrew Pinski from comment #13) > > > What is the kernel version? There has been some recent (this year) fixes > > > inside the kernel for futex. > > > > > > Though I admit I have seen this just recently when debugging a program > > > where > > > I did next over a pthread_mutex_unlock call. > > > > Was under 3.14.x. I already tried going back to 3.14.0, due to the recent > > futex security flaws covered in CVE-2014-3153. Now on 3.15.5 on the Octane, > > and my test binaries still hang, so I've pretty much ruled out it being the > > kernel. > > > > I've been doing a git bisect of gcc the last few days, and I've pinned the > > problem commit down to somewhere between Jun 12 2012 and June 26 2012. > > anything prior to the 26th works so far, anything after doesn't. My current > > bisect build is going to test June 19 2012 next. Averages about ~7.5hrs for > > gcc and 3.5hrs for glibc to build, so I can cram in roughly, 2 tests a day. > > I would try the daily date update right before > 30c3c4427521f96fb58b6e1debb86da4f113f06f commit and then bispect from there > because there are a few changes between the daily date update which could > have caused this issue. So I spent the last week bisecting as far as I can, but right around 20120620, I keep running into the same build failure about ~3hrs into the build: In file included from ../.././gcc/config/mips/mips.c:31:0: ../.././gcc/config/mips/mips.c: In function 'void mips_process_sync_loop(rtx, rtx_def**)': ../.././gcc/rtl.h:632:48: error: invalid conversion from 'long long int' to 'memmodel' [-fpermissive] #define XCWINT(RTX, N, C) ((RTX)->u.hwint[N]) In 'all-stage2-gcc'. That's right around the commit you're referencing, so I went ahead and reversed these four commits: 1. 39a8c5eaded1e5771a941c56a49ca0a5e9c5eca0 * config/mips/mips.c (mips_emit_pre_atomic_barrier_p,) 2. 974f0a74e2116143b88d8cea8e1dd5a9c18ef96c * config/mips/constraints.md (ZR): New constraint. 3. 0f8e46b16a53c02d7255dcd6b6e9b5bc7f8ec953 * config/mips/mips.c (mips_process_sync_loop): Emit cmp result only if 4. 30c3c4427521f96fb58b6e1debb86da4f113f06f * emit-rtl.c (need_atomic_barrier_p): New function. And am going to rebuild again and see if it either compiles or not. If it does compile, I'll rebuild glibc and see if the 'sln' binary works. If so, then we have the bad commits. I think all four of them go together, so I don't know if I can undo only one at a time. Thoughts? If I can save a day or two of compiling, that'd be great. Though, if these four are the problem, I still have to find a way to undo them from at least 4.8.3 to verify the c++-side of things w/ my original -lpthreads testcase. But I don't know how deeply ingrained these commits are now after ~2 years. I am guessing the changes don't impact newer MIPS processors, but I am still not sure why it's affecting only the R1x000-family. I've looked over the errata sheets I have, but nothing sticks out as a possible cause. I doubt these four commits can just be reversed entirely. The actual problem has to be found and worked around.
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 --- Comment #6 from Andrew Pinski --- This is definitely a section issue: .bss .align 3 .LANCHOR0 = . + 0 .type buf, %object .size buf, 10 buf: .hword 1 .hword 4 .hword 16 .hword 64 .hword 256 notice we are in bss rather than .data section here.
