[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306 --- Comment #1 from Nick Clifton nickc at redhat dot com 2012-08-19 07:10:01 UTC --- Created attachment 28049 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28049 Remove offending #endif
[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306 --- Comment #2 from Nick Clifton nickc at gcc dot gnu.org 2012-08-19 07:11:42 UTC --- Author: nickc Date: Sun Aug 19 07:11:35 2012 New Revision: 190511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190511 Log: PR target/54306 * config/arm/mmintrin.h: Remove spurious #endif. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/mmintrin.h
[Bug libstdc++/54320] New: [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320
Bug #: 54320
Summary: [c++11] range access to VLA
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
is range access to VLA supported?
I get compilation error for
c++ -O3 -std=gnu++11 -c vla.cpp -DVLA
with
#includealgorithm
#ifdef VLA
int foo(int N) {
int v[N];
auto a = std::begin(v);
return *a;
}
#endif
int bar() {
int v[10];
auto a = std::begin(v);
return *a;
}
[Bug c/54306] ARM iwmmxt2 commit adds imbalanced #endif in mmintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54306 --- Comment #3 from Nick Clifton nickc at redhat dot com 2012-08-19 07:13:25 UTC --- Hi Daniel, Thanks for catching this. It was a snafu, corrected with the obvious fix you suggested. Cheers Nick
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-19 07:17:04 UTC --- I don't think they can ever be as std::begin is defined as a template with one of the template arguments being the size of the array.
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-08-19 07:18:25 UTC --- See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5435
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320
--- Comment #3 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-08-19 07:24:52 UTC ---
int foo2(int N) {
int v[N];
for ( auto a : v)
if (a) return a;
return 0;
}
works, though was similar to std::begin(v) std::end(v)
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-08-19 07:30:30 UTC --- Just for the record: This problem does no longer exist in gcc 4.8 (tested for 4.8.0 20120729 (experimental))
[Bug target/54246] Bytemark FOURIER 54% slower with glibc 2.16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54246 wbrana wbrana at gmail dot com changed: What|Removed |Added Summary|Bytemark FOURIER 54% slower |Bytemark FOURIER 54% slower |in X32 chroot |with glibc 2.16 --- Comment #2 from wbrana wbrana at gmail dot com 2012-08-19 08:20:06 UTC --- It isn't related to X32, but glibc 2.16. Bug submitted: http://sourceware.org/bugzilla/show_bug.cgi?id=14496
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #18 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-19 10:54:13 UTC --- Gcc cannot alter results of an SQL query, it's a bug in your program. This is the wrong place to get help debugging your code.
[Bug c/54321] New: ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Bug #: 54321 Summary: ice in tree_low_cst at -O3 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 28050 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28050 C source code I just tried to compile the package fcron-3.0.6-5 on gcc-4.8 trunk dated 20120819 on an AMD x86_64 box. The compiler said fileconf.c: In function 'read_period': fileconf.c:1317:1: internal compiler error: in tree_low_cst, at tree.c:6546 read_period(char *ptr, cf_t *cf) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug c/54321] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-08-19 11:08:45 UTC ---
typedef struct
{
char cl_mins[0];
}
cl_t;
cl_t *a;
void fn1 ()
{
char *b = a-cl_mins;
int c = 0;
b[0] = 0;
while (++c 9)
b[c] = 255;
}
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 11:29:15 UTC --- Would be an extension requiring front-end support. I don't think we want it.
[Bug libstdc++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added Severity|normal |enhancement --- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-08-19 11:34:06 UTC --- a good candidate for c++17 then!
[Bug c++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org Component|libstdc++ |c++ --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 11:47:25 UTC --- In case we wanted to support this, it would essentially boil down to the C++ front-end bits introspecting the size. Let's ask Jason in CC, if it would make sense.
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|aschepler at gmail dot com | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 11:55:16 UTC --- Daniel can you double check? Did we regress between the end of July and now or what? Because with today's mainline the static_assert for X fires for me.
[Bug c++/54320] [c++11] range access to VLA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54320 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 12:05:57 UTC --- Frankly I'm also not sure about the signature of the begin and end overloads themselves, is it even possible to tell apart VLAs??
[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|travis at gockelhut dot com | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 12:09:54 UTC --- Daniel can you please double check this one too? Today I'm definitely seeing the undefined reference.
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-08-19 12:13:32 UTC --- (In reply to comment #2) Daniel can you double check? Good that you ask. There must by some problem with my gcc installation, because I get different results from different contexts calling gcc. I can confirm that gcc 4.8 invoked from my command line also fires the static assertion. I apologize for any confusion.
[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-08-19 12:14:53 UTC --- (In reply to comment #2) Daniel can you please double check this one too? Today I'm definitely seeing the undefined reference. It seems that I need to fix my gcc installation as described in bug 54319 - my apologies.
[Bug c++/54319] Assignment to rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 12:43:25 UTC --- No problem, let's confirm these two bugs and, hey, privately maybe let me know how it goes, maybe we can ask the help of a mingw maintainer, or something.
[Bug c++/54276] Lambda in a Template Function Undefined Reference to local static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54276 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488 Jiří Paleček jpalecek at web dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #10 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:04:34 UTC --- I found a similar preceding bugreport 52026. Therefore, I'm marking as duplicate. *** This bug has been marked as a duplicate of bug 52026 ***
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #5 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:04:34 UTC --- *** Bug 53488 has been marked as a duplicate of this bug. ***
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488 --- Comment #11 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:11:22 UTC --- BTW I have proposed a patch that fixes this problem here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01252.html. Please take a look at it.
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #6 from Jiří Paleček jpalecek at web dot de 2012-08-19 14:13:44 UTC --- BTW I have proposed a patch that fixes this problem here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01252.html. Please take a look at it.
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-19 14:38:36 UTC --- Do you have a copyright assignment on file?
[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 15:05:49 UTC --- Author: tkoenig Date: Sun Aug 19 15:05:41 2012 New Revision: 190516 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190516 Log: 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.h (struct gfc_option_t): Add warn_compare_reals. * lang.opt: Add Wcompare-reals. * invoke.texi: Document -Wcompare-reals. * resolve.c (resolve_operator): If -Wcompare-reals is in effect, warn about equality/inequality comparisions for REAL and COMPLEX. * options.c (gfc_init_options): Set warn_compare_reals. (set_Wall): Include warn_compare_reals in Wall. (gfc_handle_option): Handle Wcompare_reals. 2012-08-19 Thomas König tkoe...@gcc.gnu.org PR fortran/54298 * gfortran.dg/real_compare_1.f90: New test case. * gfortran.dg/bessel_5.f90 Add -Wno-compare-reals to options. Added: trunk/gcc/testsuite/gfortran.dg/real_compare_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_5.f90
[Bug fortran/54322] New: [OOP] Wrong TARGET-attribute handling with CLASS IS/TYPE IS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54322 Bug #: 54322 Summary: [OOP] Wrong TARGET-attribute handling with CLASS IS/TYPE IS Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Reported at comp.lang.fortran, https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/11t7gAgUGD4 The following piece of the program is invalid if PC_ALLOC is not a TARGET, however, gfortran accepts it: select type ( AN = pc_alloc ) type is ( POINT_3D ) p3d_poi=AN Note that this possibly not only affects pointer assignment but also passing as actual argument to an INTENT(IN) pointer dummy, and possibly other cases. !- LONG TEST CASE --- module mymod type POINT real :: X, Y contains procedure :: s1 = sub1 end type POINT type, extends(POINT) :: POINT_3D real :: Z end type POINT_3D type, extends(POINT) :: COLOR_POINT integer :: COLOR end type COLOR_POINT contains subroutine sub1(this) class(POINT) :: this end subroutine sub1 end module mymod ! program hello use mymod implicit none type(POINT), target :: P type(POINT_3D), target :: P3D type(COLOR_POINT), target :: CP class(POINT), pointer :: P_OR_CP class(POINT),allocatable::pc_alloc !NO TARGET class(POINT_3D),pointer ::p3d_poi P_OR_CP= CP allocate (POINT_3D :: pc_alloc) pc_alloc%X=1. pc_alloc%Y=2. select type ( AN = pc_alloc ) class is ( POINT ) ! print *, AN%X, AN%Y type is ( POINT_3D ) AN%Z=3. p3d_poi=AN ! INVALID if PC_ALLOC is not a TARGET end select print *, p3d_poi%X, p3d_poi%Y, p3d_poi%Z end program
[Bug c++/52026] [c++0x] g++: Constexpr Variable Appears Uninitialized in Lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 --- Comment #8 from Jiří Paleček jpalecek at web dot de 2012-08-19 15:38:33 UTC --- (In reply to comment #7) Do you have a copyright assignment on file? I don't know what you're talking about, so probably no. (BTW which file?)
[Bug c++/54323] New: Friend function declaration not correctly identified with CRTP + enable_if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54323
Bug #: 54323
Summary: Friend function declaration not correctly identified
with CRTP + enable_if
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vince@gmail.com
Created attachment 28051
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28051
.cpp bug example
The following example involving a friend function in a Curiously Recurring
Template Pattern base class with an enable_if default template argument is not
working :
//
#include type_traits
// Base class definition
templatetemplatetypename class CRTP, typename T class Base
{
// Friend function declaration
public:
templatetemplatetypename class CRTP0, typename T0, class
friend int func(const BaseCRTP0, T0 rhs);
// Protected test variable
protected:
int n;
};
// Friend function definition
templatetemplatetypename class CRTP0, typename T0,
class = typename std::enable_iftrue::type
int func(const BaseCRTP0, T0 rhs)
{
return rhs.n;
}
// Derived class definition
templatetypename T class Derived : public BaseDerived, T {};
// Main
int main()
{
Derivedint x;
func(x);
return 0;
}
//
g++ (tested with 4.6.1, 4.6.2 and 4.7.1) seems not to be able to match the
definition with the declaration of the function and return the following error
:
int BaseDerived, int::n' is protected
[Bug fortran/54298] Add warning when doing equal/nonequal floating-point comparisons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54298 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 16:08:37 UTC --- Fixed on trunk, closing.
[Bug fortran/54302] Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54302 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 17:01:37 UTC --- In other words, implement -Wshadow in gfortran. Makes sense. Confirmed.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-08-19 17:10:28 UTC --- (In reply to comment #3) Given the potential badness, I still think one should warn for (a) to (d). Though, one probably should think of not warning if the target has the SAVE attribute. If the target has the SAVE attribute or is allocatable, we shouldn't warn. The other question is whether the warning should be enabled by -Wall or not. (I would enable it with -Wall.) At least. Because the behavior is very likely to lead to difficult to detect bugs, I would even consider warning by default.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-19 17:27:14 UTC --- (In reply to comment #4) (In reply to comment #3) If the target has the SAVE attribute or is allocatable, we shouldn't warn. Why shouldn't one warn for ALLOCATABLE? See first example in comment 2 for a code for which I would like to warn! Submitted patch: http://gcc.gnu.org/ml/fortran/2012-08/msg00094.html
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |middle-end Target Milestone|--- |4.8.0 Summary|ice in tree_low_cst at -O3 |[4.8 Regression] ice in ||tree_low_cst at -O3
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #19 from Denis Kolesnik lirex.software at gmail dot com 2012-08-19 18:15:49 UTC --- (In reply to comment #18) Gcc cannot alter results of an SQL query, it's a bug in your program. This is the wrong place to get help debugging your code. You are right: I consider now, that it is a PostgreSQL SQL bug. limit 1 offset ... order byt str_last_name filters data wrong...
[Bug other/54324] New: GCC install document does not list minimum required g++ versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 Bug #: 54324 Summary: GCC install document does not list minimum required g++ versions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html Currently, install.texi states: @heading Tools/packages necessary for building GCC @table @asis @item ISO C90 compiler Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (KR) C compiler. To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. This appears to be out-of-date with respect to new GCC 4.8 C++ stage 1 build requirement.
[Bug c++/54214] (corrected copyright notes in source file)please help to determine whether it is an PostgreSQL error or a GCC error (combobox and SQL data sorting)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54214 --- Comment #20 from Denis Kolesnik lirex.software at gmail dot com 2012-08-19 18:21:08 UTC --- sure: I found, that the bug is if I use limit 1 clause. It is surelly a bug.
[Bug c++/54325] New: C++11 uniform initialization syntax for argument-less abstract base class constructor fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325
Bug #: 54325
Summary: C++11 uniform initialization syntax for argument-less
abstract base class constructor fails
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mor...@bunkus.org
Using {} syntax for base class initialization fails with cannot allocate an
object of abstract type 'Base' for abstract base classes with argument-less
constructors. I'll include two code samples. The first one does work with g++
4.6.1 (Ubuntu 11.10), g++ 4.6.3 (Ubuntu 12.04) and clang 3.1 but does NOT work
with g++ 4.7.0 (Ubuntu 12.04) and g++ 4.7.1 (self-compiled). The second one
works with 4.7.0 and 4.7.1 as well.
Example code that does NOT work with 4.7.x but does with older versions/other
compilers:
class Base {
public:
Base() {};
virtual ~Base() {};
virtual void do_stuff() = 0;
};
class Derived: public Base {
public:
Derived() : Base{} {};
virtual ~Derived() {};
virtual void do_stuff() {};
};
int
main() {
Derived d;
return 0;
}
Changing Base's constructor to take an additional argument lets it work
suddenly:
class Base {
public:
int m_dummy;
Base(int dummy): m_dummy{dummy} {};
virtual ~Base() {};
virtual void do_stuff() = 0;
};
class Derived: public Base {
public:
Derived() : Base{42} {};
virtual ~Derived() {};
virtual void do_stuff() {};
};
int
main() {
Derived d;
return 0;
}
$ ~/opt/gcc/4.7.1/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/mosu/opt/gcc/4.7.1/bin/g++
COLLECT_LTO_WRAPPER=/home/mosu/opt/gcc/4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-checking=release --enable-languages=c,c++
--prefix=/home/mosu/opt/gcc/4.7.1
Thread model: posix
gcc version 4.7.1 (GCC)
Actual error message:
$ ~/opt/gcc/4.7.1/bin/g++ -std=c++11 -o fails fails.cpp
fails.cpp: In constructor ‘Derived::Derived()’:
fails.cpp:11:20: error: cannot allocate an object of abstract type ‘Base’
fails.cpp:1:7: note: because the following virtual functions are pure within
‘Base’:
fails.cpp:6:16: note: virtual void Base::do_stuff()
[Bug target/54308] [4.8 regression] build regression in 190498 on ppc64/linux: legitimate_indirect_address_p undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54308 --- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-08-19 18:29:27 UTC --- (In reply to comment #6) I was unable to build 4.1.2-27.fc7 from the SRPM. I'm not sure it would have helped, seeing as the breakage was in rs6000-specific parts. So, I've given up on finding the lowest supported compiler. Ok, but see comment 4; try just removing the inline there. If necessary, the inline can be wrapped in some #ifdef construct. It depends on the maintainer to deem it acceptable of course.
[Bug other/54326] New: GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 Bug #: 54326 Summary: GCC does not build with G++ version 3.4.0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Ref: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01223.html See also: Bug #54324 (install documentation does not list the minimum required g++ version) Paul Hargrove noted the following build failure on an older x86-32 Linux (Redhat 8.0) system. The g++ version is: g++ (GCC) 3.4.0 g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/build -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libcpp/include -I/usr/local/pkg/gmp-4.2.4/include -I/usr/local/pkg/mpfr-2.4.2/include -I/usr/local/pkg/mpc-0.8/include -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber -I/usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/../libdecnumber/bid -I../libdecnumber\ -o build/genoutput.o /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c: In function `void note_constraint(rtx_def*, int)': /usr/local/pkg/upc/nightly/compiler/gupc-src/gcc/genoutput.c:1178: error: reinterpret_cast from type `const char (*)[1]' to type `char*' casts away constness make[2]: *** [build/genoutput.o] Error 1 make[2]: Leaving directory `/usr/local/pkg/upc/nightly/compiler/bld/gcc' make[1]: *** [all-gcc] Error 2
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-08-19 18:53:56 UTC --- It is caused by revision 188232: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00142.html
[Bug c/54327] New: Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327
Bug #: 54327
Summary: Segmentation fault in init_ggc
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com
I just tried to compile the package httrack-3.43.9-5
on gcc-4.8 trunk dated 20120819 on an AMD x86_64 box.
The compiler said
htslib.c: In function 'treathead':
htslib.c:1246:6: internal compiler error: Segmentation fault
void treathead(t_cookie* cookie,char* adr,char* fil,htsblk* retour,char* rcvd)
{
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Here is valgrind with some more details
==13706== Invalid read of size 4
==13706==at 0xD4FF90: linemap_location_from_macro_expansion_p(line_maps*,
un
signed int) (line-map.c:796)
==13706==by 0xD4FFCF: linemap_lookup(line_maps*, unsigned int)
(line-map.c:5
12)
==13706==by 0x8E6534:
virt_loc_aware_diagnostic_finalizer(diagnostic_context
*, diagnostic_info*) (tree-diagnostic.c:113)
==13706==by 0xD3A263: diagnostic_report_diagnostic(diagnostic_context*,
diag
nostic_info*) (diagnostic.c:652)
==13706==by 0xD3B03F: internal_error(char const*, ...) (diagnostic.c:957)
==13706==by 0x8B800F: crash_signal(int) (toplev.c:335)
==13706==by 0x3809C3599F: ??? (in /usr/lib64/libc-2.15.so)
==13706==by 0x5A7625: init_ggc() (hwint.h:264)
==13706==by 0x8B967F: toplev_main(int, char**) (toplev.c:1137)
==13706==by 0x3809C21734: (below main) (in /usr/lib64/libc-2.15.so)
==13706== Address 0x24 is not stack'd, malloc'd or (recently) free'd
==13706==
Preprocessed source code attached. Flag -O2 required.
[Bug c/54327] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 --- Comment #1 from David Binderman dcb314 at hotmail dot com 2012-08-19 20:14:08 UTC --- Created attachment 28052 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28052 gzipped C source code
[Bug middle-end/54321] [4.8 Regression] ice in tree_low_cst at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-19 20:22:39 UTC --- Created attachment 28053 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28053 gcc48-pr54321.patch The bug is pretty much obvious, val2 is first checked for host_integerp (val2, 0) but then tree_low_cst (val2, 1) is used. As the middle argument to memset is int, we should use tree_low_cst (val2, 0). I'll bootstrap/regtest this momentarily.
[Bug other/54326] GCC does not build with G++ version 3.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 --- Comment #1 from Gary Funck gary at intrepid dot com 2012-08-19 20:54:51 UTC --- Don't know if this is relevant, but a recent thread on the clang-dev list explored the differences between GCC and clang in the handling of const and constexpr. clang vs GCC error case: both ‘const’ and ‘constexpr’ cannot be used here http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-August/023565.html
[Bug c/52991] attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-08-19
20:56:19 UTC ---
The problem started with the PR27942 fix in r114552:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00569.html
http://gcc.gnu.org/ml/gcc-cvs/2006-06/msg00268.html
and it affects gcc-4.2.0 up to current trunk.
The problem isn't mingw-specific, it can be reproduced natively on e.g.
x86_64-linux. Take this C test case, reduced from #c1:
struct A {
short s;
struct { int i; } x;
} __attribute__((__packed__));
struct C {
struct { int i; } x;
short s;
} __attribute__((__packed__));
int foo(void)
{
return sizeof(struct A) == sizeof(struct C);
}
Compiling this with -mno-ms-bitfields makes foo() return 1, but compiling with
-mms-bitfields makes foo() return 0 because sizeof(struct A) then is 8 while
sizeof(struct C) still is 6.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28048|0 |1 is obsolete|| --- Comment #18 from Larry Baker baker at usgs dot gov 2012-08-19 21:18:23 UTC --- Created attachment 28054 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28054 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.md Change 16-bit word offset (the default) Bcc .+6 instruction to 8-bit short offset Bcc.S .+4 instruction (saves 2 bytes in every procedure prologue).
[Bug c/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Target Milestone|--- |4.8.0 Summary|Segmentation fault in |[4.8 Regression] |init_ggc|Segmentation fault in ||init_ggc Ever Confirmed|0 |1
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Component|c |middle-end --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-08-19 23:22:32 UTC --- It is caused by revision 189915: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00820.html
[Bug middle-end/54327] [4.8 Regression] Segmentation fault in init_ggc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-08-20 03:40:24 UTC ---
Small testcase:
#include string.h
#include stdlib.h
void treathead ()
{
char *a = ';' == '\0' ? : 0;
if (*a == '=')
{
while (*a == (*a == 0) || *a == '\'')
a++;
if (strlen (a) 2)
abort ();
}
}
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-20 05:47:55 UTC --- Author: burnus Date: Mon Aug 20 05:47:46 2012 New Revision: 190522 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190522 Log: 2012-08-20 Tobias Burnus bur...@net-b.de PR fortran/54301 * expr.c (gfc_check_pointer_assign): Warn when the pointer might outlive its target. * gfortran.h (struct gfc_option_t): Add warn_target_lifetime. * options.c (gfc_init_options, set_wall, gfc_handle_option): handle it. * invoke.texi (-Wtarget-lifetime): Document it. (-Wall): Implied it. * lang.opt (-Wtarget-lifetime): New flag. 2012-08-20 Tobias Burnus bur...@net-b.de PR fortran/54301 * gfortran.dg/warn_target_lifetime_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_target_lifetime_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-08-20 05:52:31 UTC --- FIXED on the 4.8 trunk.
