[Bug sanitizer/57774] __libc_stack_end usage is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57774 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Change what? __libc_stack_end? That would be a user error.
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #16 from Vittorio Zecca zeccav at gmail dot com ---
You are being a little too hard on me, but so be it.
I believe there is only one special case, base==0,
and that there are only two ifs to put in cpow to avoid the floating exception
and give the expected result(I am simplifying here, also because I do
not use C):
if(base==0)
{
if(exponent0) return 0; else raise hell;
}
The actual code where the original issue occurred had the exponentiation
in the deep of nested loops, it would have been rather time consuming
to test base==0
at the Fortran level
And I still do not understand why if the exponent is integer no
exception is raised and
the expected result zero is delivered.
As in the following fragment (with option -ffpe-trap=zero,invalid):
complex x
x=cmplx(0e0,0e0)
i=2
r=2e0
print *,x**i ! no exception raised delivers zero
print *,x**r ! exception raised
end
The Intel ifort and NAG nagfor compilers raise no exceptions and
deliver the expected result.
With my best wishes of good work to everybody.
[Bug c++/57775] New: default argument for template parameter error for friend definition in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57775
Bug ID: 57775
Summary: default argument for template parameter error for
friend definition in template
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cooloud at gmail dot com
MinGW4.7.2 cannot not parse a very simple code like following,
source code:
template class T=void struct X
{
friend void f(){
struct Y{}; // line 6
}
};
command and result:
C:\Users\HJg++ -v -Wall -Wextra -c tmp.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: mingw32
Configured with: ../gcc-4.7.2/configure
--enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared
--enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug
--disable-build-poststage1-
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-c' '-shared-libgcc' '-mtune=i386'
'
-march=i386'
c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/cc1plus.exe -quiet -v -iprefix
c:\min
gw\bin\../lib/gcc/mingw32/4.7.2/ tmp.cpp -quiet -dumpbase tmp.cpp -mtune=i386
-m
arch=i386 -auxbase tmp -Wall -Wextra -version -o
C:\Users\HJ\AppData\Local\Temp\
cc3msAXa.s
GNU C++ (GCC) version 4.7.2 (mingw32)
compiled by GNU C version 4.7.2, GMP version 5.0.1, MPFR version 2.4.1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../.
./mingw32/include
ignoring duplicate directory
c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.7.2/inclu
de/c++
ignoring duplicate directory
c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.7.2/inclu
de/c++/mingw32
ignoring duplicate directory
c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.7.2/inclu
de/c++/backward
ignoring duplicate directory
c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.7.2/inclu
de
ignoring duplicate directory /mingw/lib/gcc/mingw32/4.7.2/../../../../include
ignoring duplicate directory c:/mingw/lib/gcc/../../include
ignoring duplicate directory
c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.7.2/inclu
de-fixed
ignoring nonexistent directory
c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.7.2/../
../../../mingw32/include
ignoring duplicate directory /mingw/include
#include ... search starts here:
#include ... search starts here:
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/mingw32
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/backward
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include
c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include-fixed
End of search list.
GNU C++ (GCC) version 4.7.2 (mingw32)
compiled by GNU C version 4.7.2, GMP version 5.0.1, MPFR version 2.4.1,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fdc0bc7c97f61ac24bf8edb5646b3bc3
tmp.cpp: In function 'void f()':
tmp.cpp:6:11: error: default argument for template parameter for class
enclosing
'f()::Y::Y'
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 --- Comment #6 from Dimitris Papavasiliou dpapavas at gmail dot com --- Created attachment 30417 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30417action=edit Proposed patch adding switches controlling ivar scope in Objective-C.
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 --- Comment #7 from Dimitris Papavasiliou dpapavas at gmail dot com --- I made a patch for this (as well as some other minor features) and submitted it to the gcc-patches list but, since it was ignored there I'm also attaching it here in case someone decides to look at it at some point. The following is the message I posted in the list with the details of the patch: - First, let me say that I have consciously broken most of the rules mentioned about patch submission at gcc.gnu.org but I have done so in order to spare myself from wasting time to provide a proper patch in case the implemented functionality is not deemed worthy of approval and adoption into GCC. If any of the implemented switches prove to be welcome I'll be more than happy to split them into separate patches, add test-cases and add ChangLog entries as needed. Two of these switches are related to a feature request I submitted a while ago, Bug 56044 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044). I won't reproduce the entire argument here since it is available in the feature request. The relevant functionality in the patch comes in the form of two switches: -Wshadow-ivars which controls the local declaration of ‘somevar’ hides instance variable warning which curiously is enabled by default instead of being controlled at least by -Wshadow. The patch changes it so that this warning can be enabled and disabled specifically through -Wshadow-ivars as well as with all other shadowing-related warnings through -Wshadow. The reason for the extra switch is that, while searching through the Internet for a solution to this problem I have found out that other people are inconvenienced by this particular warning as well so it might be useful to be able to turn it off while keeping all the other shadowing-related warnings enabled. -flocal-ivars which when true, as it is by default, treats instance variables as having local scope. If false (-fno-local-ivars) instance variables must always be referred to as self-ivarname and references of ivarname resolve to the local or global scope as usual. I've also taken the opportunity of adding another switch unrelated to the above but related to instance variables: -fivar-visibility which can be set to either private, protected (the default), public and package. This sets the default instance variable visibility which normally is implicitly protected. My use-case for it is basically to be able to set it to public and thus effectively disable this visibility mechanism altogether which I find no use for and therefore have to circumvent. I'm not sure if anyone else feels the same way towards this but I figured it was worth a try. I'm attaching a preliminary patch against the current revision in case anyone wants to have a look. The changes are very small and any blatant mistakes should be immediately obvious. I have to admit to having virtually no knowledge of the internals of GCC but I have tried to keep in line with formatting guidelines and general style as well as looking up the particulars of the way options are handled in the available documentation to avoid blind copy-pasting. I have also tried to test the functionality both in my own (relatively large, or at least not too small) project and with small test programs and everything works as expected. Finallly, I tried running the tests too but these fail to complete both in the patched and unpatched version, possibly due to the way I've configured GCC. -- Dimitris
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- The actual code where the original issue occurred had the exponentiation in the deep of nested loops, it would have been rather time consuming to test base==0 at the Fortran level Sorry, but I don't buy the argument. The cost of the test will likely be the same in gfortran or in the library. And I still do not understand why if the exponent is integer no exception is raised and the expected result zero is delivered. When the exponent is integer, the computation is done through multiplications and zero times anything finite is zero.
[Bug lto/57776] New: [4.9 Regression] FAIL: gcc.dg/lto/pr56297 c_lto_pr56297_0.o-c_lto_pr56297_1.o link, -flto -fno-common (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57776 Bug ID: 57776 Summary: [4.9 Regression] FAIL: gcc.dg/lto/pr56297 c_lto_pr56297_0.o-c_lto_pr56297_1.o link, -flto -fno-common (internal compiler error) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: rguenth at gcc dot gnu.org The test gcc.dg/lto/pr56297 fails after revision 200151 (see http://gcc.gnu.org/ml/gcc-regression/2013-06/msg00263.html ) with (from http://glutton.geoffk.org/HEAD/native-logsum/gcc/testsuite/gcc/gcc.log.gzip ) lto1: error: node differs from symtab decl hashtable *esp/3 (i) @0xb7e94038 Type: variable definition analyzed Visibility: force_output externally_visible public References: Referring: Read from file: c_lto_pr56297_1.o Availability: overwritable Varpool flags: lto1: internal compiler error: verify_symtab_node failed 0x81bb477 verify_symtab_node(symtab_node_def*) /home/regress/tbox/svn-gcc/gcc/symtab.c:768 0x81bb497 verify_symtab() /home/regress/tbox/svn-gcc/gcc/symtab.c:780 0x839614c symtab_remove_unreachable_nodes(bool, _IO_FILE*) /home/regress/tbox/svn-gcc/gcc/ipa.c:223 0x84324e0 execute_todo /home/regress/tbox/svn-gcc/gcc/passes.c:2011 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/regress/tbox/native/build/gcc/xgcc returned 1 exit status /home/regress/tbox/objs/i686-pc-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status FAIL: gcc.dg/lto/pr56297 c_lto_pr56297_0.o-c_lto_pr56297_1.o link, -flto -fno-common (internal compiler error) UNRESOLVED: gcc.dg/lto/pr56297 c_lto_pr56297_0.o-c_lto_pr56297_1.o execute -flto -fno-common
[Bug fortran/48786] [OOP] Generic ambiguity check too strict for polymorphic dummies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-02 Ever confirmed|0 |1 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the record, the link in comment #6 is now http://mailman.j3-fortran.org/pipermail/j3/2011-May/004366.html This PR is quite difficult to follow. AFAICT the main issue has been fixed almost two years ago: (1) The errors of the kind Error: 'add_vector_3d' and 'add_vector_2d' for GENERIC '+' at (1) are ambiguous are valid. (2) The test in attachment 24141 compiles and run without error (however valgrind reports a memory leak) since revision 178509 (4.7, 2011-09-04). (3) Up to revision 177649 (2011-08-11), the test compiled but aborted at run time with Two-dimensional walk: a.out(48088) malloc: *** error for object 0x7fff5fbfd690: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug (4) The original test at https://groups.google.com/forum/?hl=it#!topic/comp.lang.fortran/4Y0ENMRlmOI gives the result expected by Salvatore Filippone and if I remove the commented lines, I get pr48786_5_db.f90:30.29: generic, public :: do = doit 1 Error: 'doit2' and 'doit' for GENERIC 'do' at (1) are ambiguous pr48786_5_db.f90:31.29: generic, public :: get = getit 1 Error: 'getit2' and 'getit' for GENERIC 'get' at (1) are ambiguous pr48786_5_db.f90:51.6: use foo2_mod 1 Fatal Error: Can't open module file 'foo2_mod.mod' for reading at (1): No such file or directory I have only one issue left: the test by Ian Harvey at https://groups.google.com/forum/#!topic/comp.lang.fortran/Sk6IX2i2YL0 gives an ICE when compiled with a clean revision 200078: pr48786_1.f90:4.43: CHARACTER(:), ALLOCATABLE :: some_text 1 Error: Deferred-length character component 'some_text' at (1) is not yet supported ... repeated several times ... f951: internal compiler error: in matching_typebound_op, at fortran/interface.c:3535 f951: internal compiler error: Abort trap gfcc: internal compiler error: Abort trap (program f951) Abort My proposal is to close this PR as fixed and to open a new one for the remaining issue. Any objection?
[Bug fortran/57469] Erroneous warning for unused dummy arguments used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57469 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Patch at http://gcc.gnu.org/ml/fortran/2013-07/msg0.html .
[Bug fortran/57522] [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 200581.
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- If it makes you happy, the following plugs the memory leak: --- a/gcc/testsuite/gfortran.dg/class_array_7.f03 +++ b/gcc/testsuite/gfortran.dg/class_array_7.f03 @@ -56,2 +56,3 @@ program main if (trim (print_type (a, a)) .ne. a is base_type) call abort + deallocate (a) end program main The reason is that gfortran no longer automatically deallocates allocatables at the end of the main program (with very few exceptions). That's in order to prevent finalization. Fortran 2008 has: A variable, common block, or procedure pointer declared in the scoping unit of a main program, module, or submodule implicitly has the SAVE attribute, which may be con rmed by explicit specification. And: 4.5.6.3 When finalization occurs: A nonpointer, nonallocatable object that is not a dummy argument or function result is finalized immediately before it would become unde ned due to execution of a RETURN or END statement (16.6.6, item (3)). which excludes SAVE: (3) When execution of an instance of a subprogram completes, (a) its unsaved local variables become undefined, Okay, that was for nonallocatables - and we have an allocatable. But there the same applies: When an allocatable entity is deallocated, it is finalized. and When the execution of a procedure is terminated by execution of a RETURN or END statement, an unsaved allocatable local variable of the procedure retains its allocation and definition status if it is a function result variable or a subobject thereof; otherwise, it is deallocated. Before finalization entered the game, it was undetectable - within the program - whether the compiler deallocated variables in the main program or not. Now, it is no longer. Hence, there is no automatic deallocation - and you see the memory leak. See also http://gcc.gnu.org/wiki/GFortran#GCC4.9
[Bug fortran/56789] Wrong code with contiguous dummy argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- On x86_64-apple-darwin10 at revision 200581, I don't get any error at run time, but valgrind complains for an Invalid write of size 4.
[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- If it makes you happy, the following plugs the memory leak: --- a/gcc/testsuite/gfortran.dg/class_array_7.f03 +++ b/gcc/testsuite/gfortran.dg/class_array_7.f03 @@ -56,2 +56,3 @@ program main if (trim (print_type (a, a)) .ne. a is base_type) call abort + deallocate (a) end program main ... Well, it makes valgrind happy. Is there any connection with PR55207 - Automatic deallocation of variables declared in the main program?
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834 --- Comment #6 from M.S. Babaei ace.of.zerosync at gmail dot com --- Hi, I'm wondering if this bug is ever going to be fixed? Unfortunately I don't know C and do not understand how inner parts of GCC works. But, it's mid 2013 and the bug first appeared on late 2006, with another duplicate in 2012. Which is also a blocker for another bug. It really bothers me, because I use GCC, Clang and VC++ at the same time. And I should put GCC specific #ifdefs and disable part of my code's functionality on GCC due to this bug. Both Clang and VC++ do not have this bug. Regards, M.S. Babaei
Makefile.in missing a definition of c-family-warn
All, I noticed that files in the c-family directory compiled during stage3 arn't using -Werror along with many other Warning flags usually applied during stage3 This to me appears to be because nothing is definng c-family-warn = $(STRICT_WARN) so any warnings specified as parrt of STRICT_WARN arn't being applied when compiling any fille within gcc/c-family Graham
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 Yuri Aksenov yuri.aksenov at gmail dot com changed: What|Removed |Added CC||yuri.aksenov at gmail dot com --- Comment #7 from Yuri Aksenov yuri.aksenov at gmail dot com --- If it's guaranteed that an uncaught exception leaving that function will still call terminate, then the catch(...) block could be removed. Maybe I could do that conditionally for targets where it's known to work as required. I vote for this enhancement to remove catch(...) block from execute_native_thread_routine function. According to standard (15.3) Handling an exception If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined (15.5.1). So if we remove catch(...), std::terminate should be called anyway (it's a bug otherwise). But GCC implementaion will leave stack unwound making it easier to debug.
[Bug c++/57746] rejected valid specialization of member function of class template (I think)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Andy Lutomirski from comment #4)
Daniel, I'm unconvinced that your interpretation is the intended one.
The definition is also a declaration, see [basic.def] p2, as Daniel pointed
out.
[temp.explicit].4 says A declaration of [list including member function]
... A definition of [list not including member function]. If definitions
were intended to be declarations in this context, then the second part would
be redundant, I think.
That doesn't follow at all. The second part describes different types of
entities that have different requirements.
For the first list an explicit instantiation must follow a declaration (and a
definition also counts as a declaration) but for the second list an explicit
instantiation must follow a definition, a declaration is not sufficient.
Regardless, the interesting case is:
templatetypename T
struct X
{
static int val;
static void func();
};
// optionally: extern template struct Xint;
void something()
{
Xint::func();
}
in one file and
struct X
{
static int val;
static void func();
};
template void Xint::func() {}
in another. I don't think this is an odr violation, since there is only one
definition of anything that could be confused with Xint::func. g++ will
happily compile and link it (without the extern template bit) and it will
work. It is supposed to? Could a conforming compiler mangle the
specialized version of func differently?
Isn't this ill-formed, with no diagnostic required, by both [temp] p6 and
[temp.expl.spec] p6?
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
You can use list-initialization to workaround it:
Doh{x}, ++x;
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #18 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
On Tue, Jul 02, 2013 at 07:21:54AM +, zeccav at gmail dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #16 from Vittorio Zecca zeccav at gmail dot com ---
and that there are only two ifs to put in cpow to avoid the floating exception
and give the expected result(I am simplifying here, also because I do
not use C):
if(base==0)
{
if(exponent0) return 0; else raise hell;
}
The actual code where the original issue occurred had the exponentiation
in the deep of nested loops, it would have been rather time consuming
to test base==0
at the Fortran level
It will be time consuming wherever it is tested. That's my
entire point and why the C11 standard permits cpow(z,c) to
be implemented as cexp(c*clog(z)) without trying to deal
with all of the special cases (or accuracy issues).
And I still do not understand why if the exponent is integer no
exception is raised and
the expected result zero is delivered.
As in the following fragment (with option -ffpe-trap=zero,invalid):
complex x
x=cmplx(0e0,0e0)
i=2
r=2e0
print *,x**i ! no exception raised delivers zero
The compiler knows that i is an integer, and the above case
it is 2. The compiler evaluates x**2 as x*x.
print *,x**r ! exception raised
end
The Intel ifort and NAG nagfor compilers raise no exceptions and
deliver the expected result.
While it may be possible for a compiler to determine that r in
r=2e0 is an integral value of 2 and replace x**r by x*x, I suspect
that it will fail in the general case. What does
r = 8.125
x = (0.,0.)
print *, x**r ! x**8 * sqrt(sqrt(sqrt(x))) = 0.
or
r = 1. / 3
x = (0.,0,)
print *, x**r ! cube root of x?
produce?
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Yuri Aksenov from comment #7) If it's guaranteed that an uncaught exception leaving that function will still call terminate, then the catch(...) block could be removed. Maybe I could do that conditionally for targets where it's known to work as required. I vote for this enhancement to remove catch(...) block from execute_native_thread_routine function. This isn't a democracy ;) According to standard (15.3) Handling an exception If no matching handler is found, the function std::terminate() is called; whether or not the stack is unwound before this call to std::terminate() is implementation-defined (15.5.1). So if we remove catch(...), std::terminate should be called anyway (it's a bug otherwise). The catch(...) is there to provide the [thread.thread.constr]/4 requirement that std::terminate is called. If it isn't there, are you saying Pthreads or the OS guarantees that an exception in the function passed to pthread_create() will cause a call to std::terminate()? Where is that guaranteed? Where is it implemented? You can't just say rely on the implementation, it's a bug otherwise, this code **is** the implementation.
[Bug c/57777] New: Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Bug ID: 5 Summary: Python module fails compilation with -march=core-avx2 -O3 Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dirkjan at ochtman dot nl gcc-4.7 -march=core-avx2 -O3 - fails gcc-4.7 -march=core-avx2 -O2 - succeeds gcc-4.7 -march=core-avx-i -O3 - succeeds gcc-4.7 -march=core-avx-i -O2 - succeeds gcc-4.6 -march=core-avx-i -O3 - succeeds gcc-4.6 -march=core-avx-i -O2 - succeeds Failure happens like this: building '_random' extension x86_64-pc-linux-gnu-gcc -pthread -fPIC -fno-strict-aliasing -march=core-avx2 -O2 -pipe -Wall -g -O3 -fwrapv -DNDEBUG -I. -IInclude -I/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Include -I/var/tmp/portage/dev-lang/python-2.7.5/work/x86_64-pc-linux-gnu -c /var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.c -o build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -L. -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -L. -fno-strict-aliasing -march=core-avx2 -O2 -pipe -Wall -g -O3 -fwrapv -DNDEBUG -I. -IInclude -I/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Include build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o -L/usr/local/lib -L. -lpython2.7 -o build/lib.linux-x86_64-2.7/_random.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/bin/ld: build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC build/temp.linux-x86_64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_randommodule.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status
[Bug c/57777] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #1 from Dirkjan Ochtman dirkjan at ochtman dot nl --- See https://bugs.gentoo.org/show_bug.cgi?id=475482 for more information.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- P.S. I do want to improve the behaviour, and I think we can make a change for targets where we know the behaviour is OK, but we need to check carefully that it works correctly, not just remove the catch(...)
[Bug c/57777] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Please provide preprocessed source of _randommodule.c
[Bug tree-optimization/57741] ICE in tree.c:build_int_cst_wide starting in revision 200394
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57741 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Jul 2 11:54:09 2013 New Revision: 200600 URL: http://gcc.gnu.org/viewcvs?rev=200600root=gccview=rev Log: PR tree-optimization/57741 * tree-vect-loop.c (vect_is_simple_iv_evolution): Disallow non-INTEGRAL_TYPE_P non-SCALAR_FLOAT_TYPE_P SSA_NAME step_exprs, or SCALAR_FLOAT_TYPE_P SSA_NAMEs if !flag_associative_math. Allow REAL_CST step_exprs if flag_associative_math. (get_initial_def_for_induction): Handle SCALAR_FLOAT_TYPE_P step_expr. * gcc.dg/vect/pr57741-1.c: New test. * gcc.dg/vect/pr57741-2.c: New test. * gcc.dg/vect/pr57741-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr57741-1.c trunk/gcc/testsuite/gcc.dg/vect/pr57741-2.c trunk/gcc/testsuite/gcc.dg/vect/pr57741-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #10 from Yuri Aksenov yuri.aksenov at gmail dot com --- OK, [thread.thread.constr]/4 says: If the invocation of INVOKE(decay_copy( std::forwardF(f)), decay_copy(std::forwardArgs(args))...) terminates with an uncaught exception, std::terminate shall be called. And [except.handle]/9 says: If no matching handler is found, the function std::terminate() is called So we don't need to set default handler unless there is bug in implementation of [except.handle]/9 I have tested std::thread with removed catch(...) for both -m32 and -m64 environments on gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) Target: x86_64-suse-linux And I can test it on Target: armv5b-softfloat-linux But I can not be shure for any possible target
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #8 from M.S. Babaei ace.of.zerosync at gmail dot com ---
(In reply to Jonathan Wakely from comment #7)
You can use list-initialization to workaround it:
Doh{x}, ++x;
Thanks for the reply. Yeah, it did the trick for GCC 4.4+. And, I've never
thought of that.
But this is a bug, and I see no reason why it hasn't been fixed anyway.
However, your solution works fine with only C++11 enabled projects. Although,
this is not a problem for me, because it has been virtually three years that my
default mode for any new project is C++11. But, it might still be a problem for
others.
Thanks again, you saved me a lot of headaches.
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #11 from Yuri Aksenov yuri.aksenov at gmail dot com --- Where is that guaranteed? Where is it implemented? And here is stack trace of patched version, it seems to be implemented in __cxxabiv1::__cxa_throw (gdb) bt #0 0x7703ad25 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7703c1a8 in __GI_abort () at abort.c:91 #2 0x7791d68d in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x7791b796 in __cxxabiv1::__terminate (handler=optimized out) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:40 #4 0x7791b7c3 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:50 #5 0x7791b9ee in __cxxabiv1::__cxa_throw (obj=0x7940, tinfo=optimized out, dest=optimized out) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:83 #6 0x004010f2 in f () at main.cpp:5 #7 0x0040242d in std::_Bind_simplevoid (*())()::_M_invoke(std::_Index_tuple) (this=0x606040) at /usr/include/c++/4.7/functional:1598 #8 0x0040237d in std::_Bind_simplevoid (*())()::operator()() (this=0x606040) at /usr/include/c++/4.7/functional:1586 #9 0x00402316 in std::thread::_Implstd::_Bind_simplevoid (*())() ::_M_run() (this=0x606028) at /usr/include/c++/4.7/thread:115 #10 0x0040266d in std::(anonymous namespace)::execute_native_thread_routine (__p=0x606028) at thread.cpp:73 #11 0x77bc6e0e in start_thread (arg=0x77005700) at pthread_create.c:305 #12 0x770ea2cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
[Bug c/57777] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Julian Ospald julian.ospald at googlemail dot com changed: What|Removed |Added CC||julian.ospald at googlemail dot co ||m --- Comment #3 from Julian Ospald julian.ospald at googlemail dot com --- Created attachment 30418 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30418action=edit _randommodule-preprocessed.c
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #11 from Pierre Ossman ossman at cendio dot se --- Created attachment 30419 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30419action=edit main.c We've also been hitting this, so here is a reduced test case to provoke the bug. Output in the failing case: test_spans(nspans=36) 101,100 + 1 101,0 + 1 0,100 + 0 Aborted (core dumped) And for a correct run: test_spans(nspans=36) 101,100 + 1 101,100 + 1 101,100 + 1 101,100 + 1 101,101 + 1 101,101 + 1 101,99 + 1 101,99 + 1 101,102 + 1 ...
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #12 from Pierre Ossman ossman at cendio dot se --- Created attachment 30420 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30420action=edit Makefile
[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083 --- Comment #13 from Pierre Ossman ossman at cendio dot se --- This was tested using gcc 4.7.2 and gcc 4.5.3.
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834 --- Comment #9 from James Kanze james.kanze at gmail dot com --- Re using the init list syntax: it won't work if you have to be compatible with other compilers (like Sun CC). Using something like (Doh (x)), ++x seems to be the most portable work-around.
[Bug fortran/57778] New: Missing warning for -Wimplicit-procedure for dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57778 Bug ID: 57778 Summary: Missing warning for -Wimplicit-procedure for dummy arguments Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Based on https://groups.google.com/forum/#!topic/comp.lang.fortran/3idUN6kMjjo The following program should give a warning with -Wimplicit-procedure - but it doesn't. Expected: * Intel (no special options): z.f90(14): warning #6717: This name has not been given an explicit type. [FUN] subroutine l1(inp,fun,outp) --^ * gfortran (for non dummy arguments): Warning: Procedure 'fun' called at (1) is not explicitly declared Note: -Wimplicit-procedure does not warn when one uses EXTERNAL. Seemingly, the using it as dummy argument someone creates an EXTERNAL attribute - at least there is no warning in the following case. module subs implicit none !! The following is in the original code, but not relevant for this PR !! However, the warning is also required with this code. ! interface ! subroutine fun(inp,outp) ! real,intent(in) :: inp ! real,intent(out) :: outp ! end subroutine fun ! end interface contains subroutine l1(inp,fun,outp) implicit none real,intent(in) :: inp real,intent(out) :: outp call fun(inp,outp) end subroutine l1 end module subs
[Bug fortran/57778] Missing warning for -Wimplicit-procedure for dummy arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57778 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Additionally, I wonder whether one wants to have a means to require an explicit interface, i.e. not just an explicit EXTERNAL (with implicit interface).
[Bug c/57777] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 CC||areg.melikadamyan at gmail dot com Ever confirmed|0 |1 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- The problem is in .text vpgatherqq %ymm8, mag01.10849(,%ymm6,8), %ymm5 .section.rodata .align 16 .type mag01.10849, @object .size mag01.10849, 16 mag01.10849: .quad 0 .quad 2567483615 mag01.10849(,%ymm6,8) isn't PC relative.
[Bug tree-optimization/57701] Incorrect optimisation of inlined function with inline assembly when cross-compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701 --- Comment #5 from sqweek sqweek at gmail dot com --- Hahaha, that amuses me probably more than it should! Thanks for chiming in Hans, it would have taken me forever to figure that out :)
[Bug libstdc++/55917] Impossible to find/debug unhandled exceptions in an std::thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Yes it will probably work on all platforms using the Itanium exception-handling ABI, unless the OS's pthread_create (or equiv) has explicit exception-handling.
[Bug libstdc++/57779] New: vector insert fails to diagnose iterators pointing into *this in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57779
Bug ID: 57779
Summary: vector insert fails to diagnose iterators pointing
into *this in debug mode
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vlukas at gmx dot de
When using the libstdc++ debug mode, some invalid iterator uses are not
diagnosed, e.g. the following program compiles and runs without aborting / any
diagnostic:
--
#include vector
int main() {
std::vectorint v(1, 1);
v.insert(v.begin(), v.begin(), v.end());
}
---
In the call to vector::insert, the range to insert points into the vector to
insert into. This violates the precondition as specified for sequence
containers. A similar precondition exists for sequence container assign members
and maybe others. It would be nice if this misusage could be diagnosed.
The matter is a bit more complicated because in a insert(p, i, j) call, i and
j may be arbitrary input iterators forming a range. Example:
---
#include vector
int main() {
std::vectorint v(1, 1);
v.insert(v.begin(), v.data(), v.data() + 1);
}
Here the iterators i and j are plain pointers.
The full compiler command line I used was:
---
c++ -Wall -Wextra -pedantic -std=c++0x -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC -o
container_insert_iterators_into_container.debug_enhancement
container_insert_iterators_into_container.debug_enhancement.cc -g
-fstack-protector-all -pthread
-
The output of c++ -v is:
--
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7
--enable-ssp --disable-libssp --disable-libitm --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.7 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.7.3 (SUSE Linux)
--
[Bug middle-end/57780] New: Waste work in subst_dup()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57780 Bug ID: 57780 Summary: Waste work in subst_dup() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30421 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30421action=edit Suggested patch The problem appears in the revision 200588 in version 4.9. I attached a simple patch that fixes it. In method subst_dup in gensupport.c, the loop on line 2181 should not be executed when code equals to MATCH_DUP or MATCH_OP_DUP. When code != MATCH_DUP code != MATCH_OP_DUP is FALSE, all the iterations do not perform any useful work.
[Bug c++/57781] New: g++ 4.7 segfaults on trivial example program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57781 Bug ID: 57781 Summary: g++ 4.7 segfaults on trivial example program Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: larsmans at gmail dot com Created attachment 30422 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30422action=edit Preprocessed source code that triggers the bug Using GCC 4.7.3 from Debian: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.3-4' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.3 (Debian 4.7.3-4) On the attached preprocessed C++ source file, the compiler segfaults: $ g++ -c a.ii a.cc:3:17: warning: non-static data member initializers only available with -std=c++11 or -std=gnu++11 [enabled by default] a.cc: In constructor ‘A::B::B()’: a.cc:2:12: internal compiler error: Segmentation fault Similarly in C++11 mode: $ g++ -std=c++11 -c a.ii a.cc: In constructor ‘constexpr A::B::B()’: a.cc:2:12: internal compiler error: Segmentation fault
[Bug middle-end/57782] New: Waste work in remove_path()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782 Bug ID: 57782 Summary: Waste work in remove_path() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30423 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30423action=edit Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a patch that fixes it. In method remove_path() in cfgloopmanip.c, the loop on line 343 should break immediately after irred_invalidated is set to true. All the iterations after irred_invalidated set to true do not perform any useful work, at best they just set irred_invalidated again to true.
[Bug c++/57781] g++ 4.7 segfaults on trivial example program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57781 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup *** This bug has been marked as a duplicate of bug 57770 ***
[Bug c++/57770] non-static data member initializer in nested class and default value in constructor cause compiler segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57770 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||larsmans at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 57781 has been marked as a duplicate of this bug. ***
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 --- Comment #30 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Thu Jun 27 13:49:28 2013 New Revision: 200468 URL: http://gcc.gnu.org/viewcvs?rev=200468root=gccview=rev Log: 2013-06-27 Martin Jambor mjam...@suse.cz PR lto/57208 * ipa-ref.h (ipa_maybe_record_reference): Declare. * ipa-ref.c (ipa_maybe_record_reference): New function. * cgraphclones.c (cgraph_create_virtual_clone): Use it. * ipa-cp.c (create_specialized_node): Record potential references from aggvals. * Makefile.in (ipa-ref.o): Add IPA_REF_H to dependencies. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/cgraphclones.c trunk/gcc/ipa-cp.c trunk/gcc/ipa-ref.c trunk/gcc/ipa-ref.h
[Bug c++/57208] Latest chromium compilation fails with enabled LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #31 from Martin Jambor jamborm at gcc dot gnu.org --- All right. I hope the PR can be closed now. Please re-open if the bug is istill present.
[Bug c++/57783] New: Silly instantiation of class template when using dependent type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57783
Bug ID: 57783
Summary: Silly instantiation of class template when using
dependent type
Product: gcc
Version: 4.4.7
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ibugs at qult dot net
The following code fails to compile on GCC 4.4.7, while it succeeds on 3.3.6,
4.5.3, 4.6.3, 4.6.4 and 4.7.3.
template class T1, class T2
struct Two {
T1a;
T2b;
Two(const T1 a_, const T2 b_) : a(a_), b(b_) {}
template class U1, class U2
Two(const TwoU1, U2 t) : a(t.a), b(t.b) {}
};
template class T1, class T2
TwoT1, T2make_two(T1 a, T2 b) {
return TwoT1, T2(a, b);
}
struct Empty {};
template class Base
struct Foo : Base {
typedef booltype;
Twobool, type*f();
};
template class Base
Twobool, typename FooBase::type*
FooBase::f() {
return make_two(false, (type*) 0);
}
int main()
{
FooEmpty().f();
return 0;
}
Apparently the instantiation mechanism somehow has trouble dealing with
FooBase::type and doesn't identify this with the exact type (bool).
The very curious fact is that the error message starts with:
In instantiation of 'Foobool':
which makes me wonder, how comes GCC wants to instantiate a class template with
some completely random parameter.
This seems to be fixed in later releases, but I haven't been able to pinpoint
the actual report and fix. So I report that specific case just to be sure that
problem won't resurrect in the future.
[Bug c++/57783] Silly instantiation of class template when using dependent type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57783 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- GCC 4.4 is no longer supported or maintained, but as you say it works in currently supported versions.
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to M.S. Babaei from comment #8) But this is a bug, and I see no reason why it hasn't been fixed anyway. I see plenty of reasons: It is a obscure bug, there are easy work-arounds, there are very few G++ developers (maybe 4-5 sporadic and two full-time? I am not even sure they are actually full-time...), and there are literally thousands of other bugs requiring attention. Any help would be welcome. Unfortunately I don't know C and do not understand how inner parts of GCC works. G++ is written in C++. The C++ FE is mostly isolated from other parts of the compiler and the parser is almost solely contained in gcc/cp/parser.c. If you know enough C++, you should be able to follow what it does. I am not saying it is pretty or easy, but it is doable. If you can use a debugger, you could figure out why g++ is getting confused here and what it should do instead.
[Bug driver/57784] New: GCC inadvertedly truncates source text
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784 Bug ID: 57784 Summary: GCC inadvertedly truncates source text Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: mtodorov3_69 at yahoo dot com The example goes as follows: The line: # gcc -o mypatch mypatch.cc -lstdc++ is mistyped as: # gcc -o mypatch.cc -lstdc++ GCC complains about no main() and truncates the C++ source to zero length! Correct would be to complain about wrong number of arguments before doing any action on mypatch.cc. Would it hurt to check suffix of the file referenced by -o option, if it is common that object file is overwritten? Few executables' names end with .cc or .c. Fortunatelly, the source was recovered with minimal loss of changes from backup location :-) Greetz, mt
[Bug target/57777] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase for -O3 -mavx2 -fpic:
void
foo (unsigned long *x, int *y)
{
static unsigned long b[2] = { 0x0UL, 0x9908b0dfUL };
int c;
for (c = 0; c 512; c++)
x[c] = b[x[c] 1UL];
}
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #19 from Harald Anlauf anlauf at gmx dot de ---
(In reply to Vittorio Zecca from comment #16)
You are being a little too hard on me, but so be it.
I believe there is only one special case, base==0,
and that there are only two ifs to put in cpow to avoid the floating
exception
and give the expected result(I am simplifying here, also because I do
not use C):
if(base==0)
{
if(exponent0) return 0; else raise hell;
}
The actual code where the original issue occurred had the exponentiation
in the deep of nested loops, it would have been rather time consuming
to test base==0
at the Fortran level
And I still do not understand why if the exponent is integer no
exception is raised and
the expected result zero is delivered.
As in the following fragment (with option -ffpe-trap=zero,invalid):
complex x
x=cmplx(0e0,0e0)
i=2
r=2e0
print *,x**i ! no exception raised delivers zero
print *,x**r ! exception raised
end
The Intel ifort and NAG nagfor compilers raise no exceptions and
deliver the expected result.
With my best wishes of good work to everybody.
You obviously haven't tried other compilers.
With xlf, the result also depends on compiler flags:
Either (0.,0.), (NaNQ,NaNQ), or
Trace/BPT trap (core dumped)
I think you should accept that your code invokes undefined behavior
and needs fixing.
[Bug fortran/57785] New: DOT_PRODUCT error with constant complex array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785 Bug ID: 57785 Summary: DOT_PRODUCT error with constant complex array Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: konstant at mail dot ntua.gr GNU Fortran (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 Code: print *, 'z.z= ',DOT_PRODUCT ((/ (1.0, 2.0), (2.0, 3.0) /), (/ (1.0, 1.0), (1.0, 4.0) /)) print *, 'z.z= ',SUM( CONJG((/ (1.0, 2.0), (2.0, 3.0) /))*(/ (1.0, 1.0), (1.0, 4.0) /)) produces z.z= ( -11.000, 14.000) z.z= ( 17.000, 4.) The first one is wrong. With GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3 the result is correct: z.z= ( 17.00, 4.000) z.z= ( 17.00, 4.000) Generating complex numbers e.g. complex(8) :: z1(2),z2(2) real (8) :: rez(2),imz(2) call random_number(rez);call random_number(imz);z1=DCMPLX(rez,imz) call random_number(rez);call random_number(imz);z2=DCMPLX(rez,imz) print *, 'z1.z2=',DOT_PRODUCT(z1,z2) print *, 'z1.z2=',SUM(DCONJG(z1)*z2) produces correct results for many tries.
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #20 from Vittorio Zecca zeccav at gmail dot com --- I did try Intel ifort and NAG nagfor, as I already wrote, and also Solaris sunf90, and all of them accept complex zero raised to an integer or real power greater than zero, without raising any exception end delivering zero, the result I expected. It also works with a complex exponent whose real part is greater than zero, and zero imaginary part. I have not xlf, so I could not try it. Also, I understand the responsibility for the exponentiation behaviour is in glibc, not gfortran, so we may well close the discussion here.
[Bug fortran/57749] -ffpe-trap=zero or invalid produces SIGFPE on complex zero ** 1e0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749 --- Comment #21 from Vittorio Zecca zeccav at gmail dot com --- If the cost is the same, this is a good reason to let the library handle this special case and let the programmer think about his/her business. Shouldn't system software ease the life of programmers? Shouldn't gfortran be consistent and raise the exception all the time, with integer real and complex exponent, or never? I mean, if the complex exponentiation has a (essential) singularity there, this is regardless of the Fortran type of the exponent. About portability, on my AMD 64 bit CPU with Fedora 18 I confirm that Intel ifort, NAG nagfor, and Solaris sunf95 do not raise any exception and deliver zero. A Fortran programmer may not know C and may think that a bad ** is a Fortran implementation issue. Anyway, I am preparing a note for the glibc people.
[Bug c++/57746] rejected valid specialization of member function of class template (I think)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #6 from Andy Lutomirski luto at mit dot edu ---
Jonathan Wakely wrote in comment #4:
(In reply to Andy Lutomirski from comment #4)
[temp.explicit].4 says A declaration of [list including member function]
... A definition of [list not including member function]. If definitions
were intended to be declarations in this context, then the second part would
be redundant, I think.
That doesn't follow at all. The second part describes different types of
entities that have different requirements.
For the first list an explicit instantiation must follow a declaration (and a
definition also counts as a declaration) but for the second list an explicit
instantiation must follow a definition, a declaration is not sufficient.
Ugh. In that case, [temp.explicit].4 is irrelevant. I guess it means that, if
you explicitly instantiate something, then a declaration and/or definition must
happen before that instantiation, and it probably doesn't mean that a
declaration and/or definition can't follow that explicit instantiation.
Regardless, the interesting case is:
templatetypename T
struct X
{
static int val;
static void func();
};
// optionally: extern template struct Xint;
void something()
{
Xint::func();
}
in one file and
struct X
{
static int val;
static void func();
};
template void Xint::func() {}
in another. I don't think this is an odr violation, since there is only one
definition of anything that could be confused with Xint::func. g++ will
happily compile and link it (without the extern template bit) and it will
work. It is supposed to? Could a conforming compiler mangle the
specialized version of func differently?
Isn't this ill-formed, with no diagnostic required, by both [temp] p6 and
[temp.expl.spec] p6?
...so this proves that I know considerably less about C++ templates than I
thought I did. Apparently even a translation unit containing exactly:
templatetypename T void func();
void caller()
{
funcint();
}
is ill-formed. I wonder why. g++ and clang++ both accept it, I think (from
memory) that MSVC accepts it as well, and I wouldn't be surprised if there are
quite a few libraries that rely on this behavior.
[Bug middle-end/57786] New: Waste work in distribute_notes()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57786 Bug ID: 57786 Summary: Waste work in distribute_notes() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30424 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30424action=edit Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a one-line patch that fixes it. In method distribute_notes() in combine.c, the loop on line 13584 should break immediately after all_used is set to 0. All the iterations after all_used set to 0 do not perform any useful work, at best they just set all_used again to 0.
[Bug target/57363] IBM long double: adding NaN and number raises inexact exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #1 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Adhemerval Zanella from comment #0) Adding any number to NaN should not raise any exception. Not quite true -- QNaN should not raise any exception, but SNaN should raise Invalid.
[Bug target/57777] [4.7/4.8/4.9 Regression] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4 Summary|Python module fails |[4.7/4.8/4.9 Regression] |compilation with|Python module fails |-march=core-avx2 -O3 |compilation with ||-march=core-avx2 -O3
[Bug target/57777] [4.7/4.8/4.9 Regression] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30425 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30425action=edit gcc49-pr5.patch Untested fix.
[Bug target/57787] New: Waste work in ix86_valid_target_attribute_inner_p() and ix86_pad_returns()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787 Bug ID: 57787 Summary: Waste work in ix86_valid_target_attribute_inner_p() and ix86_pad_returns() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30426 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30426action=edit Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a simple patch that fixes it. In method ix86_valid_target_attribute_inner_p() in i386.c, the loop on line 4325 should break immediately after ret is set to false. All the iterations after ret set to false do not perform any useful work, at best they just set ret again to false. Also, in method ix86_pad_returns(), the loop on line 35744 should break immediately after replace is set to true. All the iterations after replace set to true do not perform any useful work, at best they just set replace again to true.
[Bug c++/57788] New: Waste work in maybe_deduce_size_from_array_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57788 Bug ID: 57788 Summary: Waste work in maybe_deduce_size_from_array_init Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30427 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30427action=edit Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a one-line patch that fixes it. In method maybe_deduce_size_from_array_init() in decl.c, the loop on line 4839 should break immediately after failure is set to 1. All the iterations after failure set to 1 do not perform any useful work, at best they just set failure again to 1.
[Bug c++/57788] Waste work in maybe_deduce_size_from_array_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57788 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- (In reply to Po-Chun Chang from comment #0) Created attachment 30427 [details] Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a one-line patch that fixes it. In method maybe_deduce_size_from_array_init() in decl.c, the loop on line 4839 should break immediately after failure is set to 1. All the iterations after failure set to 1 do not perform any useful work, at best they just set failure again to 1. Actual errors are reported as diagnostic inside the function check_array_designated_initializer(), so the loop can't break prematurely.
[Bug middle-end/57789] New: Waste work in repo_emit_p()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57789 Bug ID: 57789 Summary: Waste work in repo_emit_p() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30428 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30428action=edit Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a one-line patch that fixes it. In method repo_emit_p() in repo.c, the loop on line 342 should break immediately after emit_p is set to 1. All the iterations after emit_p set to 1 do not perform any useful work, at best they just set emit_p again to 1.
[Bug middle-end/57790] New: Waste work in can_move_insns_across()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790 Bug ID: 57790 Summary: Waste work in can_move_insns_across() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30429 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30429action=edit Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a one-line patch that fixes it. In method can_move_insns_across() in df-problems.c, the loop on line 4038 should break immediately after fail is set to 1. All the iterations after fail set to 1 do not perform any useful work, at best they just set fail again to 1.
[Bug fortran/57785] DOT_PRODUCT error with constant complex array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 CC||burnus at gcc dot gnu.org, ||franke.daniel at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The following change print *, 'z.z= ',DOT_PRODUCT ((/ (1.0, 2.0), (2.0, 3.0) /), (/ (1.0, 1.0), (1.0, 4.0) /)) print *, 'z.z= ',SUM( CONJG((/ (1.0, 2.0), (2.0, 3.0) /))*(/ (1.0, 1.0), (1.0, 4.0) /)) print *, 'z.z= ',SUM( (/ (1.0, 2.0), (2.0, 3.0) /)*(/ (1.0, 1.0), (1.0, 4.0) /)) end gives z.z= ( -11.00, 14.00) z.z= ( 17.00, 4.000) z.z= ( -11.00, 14.00) i.e., DOT_PRODUCT applied to constant vectors does not implement CONJG of the first vector. If I am not mistaken, the computation is done in compute_dot_product as case BT_INTEGER: case BT_REAL: case BT_COMPLEX: result = gfc_add (result, gfc_multiply (gfc_copy_expr (a), gfc_copy_expr (b))); break; default: gcc_unreachable(); in fortran/simplify.c (if I comment the line case BT_COMPLEX: the compilation reaches the following gcc_unreachable();). This is right for MATMUL, but not for DOT_PRODUCT for which compute_dot_product is called from gfc_simplify_dot_product as return compute_dot_product (vector_a, 1, 0, vector_b, 1, 0); The code has been introduced in revision 148243. I think the fix should be applied in gfc_simplify_dot_product by applying gfc_simplify_conjg to vector_a if it complex.
[Bug middle-end/57789] Waste work in repo_emit_p()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57789 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- /* There is no early exit from this loop because we want to ensure that all of the clones are marked as available in this object file. */ There is a comment before this loop on why this is not a valid thing to do.
[Bug middle-end/57790] Waste work in can_move_insns_across()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed. Patches go to gcc-patches@ after a bootstrap/test.
[Bug fortran/57791] New: Waste work in gfc_check_pointer_assign()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791 Bug ID: 57791 Summary: Waste work in gfc_check_pointer_assign() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu Created attachment 30430 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30430action=edit Suggested patch The problem appears in revision 200588 in version 4.9. I have attached a one-line patch that fixes it. In method gfc_check_pointer_assign() in expr.c, the loop on line 3763 should break immediately after warn is set to true. All the iterations after warn set to true do not perform any useful work, at best they just set warn again to true.
[Bug c++/57788] Waste work in maybe_deduce_size_from_array_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57788 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Po-Chun Chang from comment #1) Actual errors are reported as diagnostic inside the function check_array_designated_initializer(), so the loop can't break prematurely. Invalid based on this comment.
[Bug target/57787] Waste work in ix86_valid_target_attribute_inner_p() and ix86_pad_returns()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The first one you cannot do because of error messages that could be outputted. The second one looks correct. Again patches should be sent to gcc-patches@.
[Bug c++/57746] rejected valid specialization of member function of class template (I think)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #7 from Daniel Krügler daniel.kruegler at googlemail dot com ---
(In reply to Andy Lutomirski from comment #4)
Daniel, I'm unconvinced that your interpretation is the intended one.
Well, [temp.spec] p5 says more strongly that an explicit instantiation shall
only follow a declaration of an explicit specialization:
For a given template and a given set of template-arguments,
— an explicit instantiation definition shall appear at most once in a program,
— an explicit specialization shall be defined at most once in a program
(according to 3.2), and
— both an explicit instantiation and a declaration of an explicit
specialization shall not appear in a program unless the explicit instantiation
follows a declaration of the explicit specialization.
An implementation is not required to diagnose a violation of this rule.
This is in agreement of my interpretation of [temp.explicit] p4.
Regardless, the interesting case is:
templatetypename T
struct X
{
static int val;
static void func();
};
// optionally: extern template struct Xint;
void something()
{
Xint::func();
}
in one file and
struct X
{
static int val;
static void func();
};
template void Xint::func() {}
This code is not supported by the standard:
a) If the explicit instantiation declaration is provided, this violates above
quoted bullet 3 (you missed to declare the explicit specialization before). In
addition to that [temp.explicit] p11 requires the existence of an explicit
instantiation definition of Xint::func():
An entity that is the subject of an explicit instantiation declaration and
that is also used in a way that would otherwise cause an implicit instantiation
(14.7.1) in the translation unit shall be the subject of an explicit
instantiation definition somewhere in the program; otherwise the program is
ill-formed, no diagnostic required.
b) If the explicit instantiation declaration is *not* provided, Xint::func()
is implicitly instantiated, but you provide an explicit instantiation instead.
This violates [temp.spec] p4:
An instantiated template specialization can be either implicitly instantiated
(14.7.1) for a given argument list or be explicitly instantiated (14.7.2). A
specialization is a class, function, or class member that is either
instantiated or explicitly specialized (14.7.3).
More strongly, [temp.expl.spec] p6 says:
If a template, a member template or a member of a class template is explicitly
specialized then that specialization shall be declared before the first use of
that specialization that would cause an implicit instantiation to take place,
in every translation unit in which such a use occurs; no diagnostic is
required.
You don't have the explicit specialization of Xint::func() declared in the
first TU that implicitly instantiates this member.
[Bug c++/57746] Invalid specializations of member objects are accepted, unlike member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746 Andy Lutomirski luto at mit dot edu changed: What|Removed |Added Summary|rejected valid |Invalid specializations of |specialization of member|member objects are |function of class template |accepted, unlike member |(I think) |functions --- Comment #8 from Andy Lutomirski luto at mit dot edu --- OK, I'm convinced. I renamed the bug accordingly.
[Bug target/57777] [4.7/4.8/4.9 Regression] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #7 from Julian Ospald julian.ospald at googlemail dot com --- (In reply to Jakub Jelinek from comment #6) Created attachment 30425 [details] gcc49-pr5.patch Untested fix. I have tested that patch on gcc-4.8 and was able to compile the python module successfully with -march=core-avx2 -O3. gcc-4.8 is affected as well without that patch, as the title correctly says.
[Bug target/57777] [4.7/4.8/4.9 Regression] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #8 from Julian Ospald julian.ospald at googlemail dot com --- tested with gcc-4.7.3, and it works as well for clarification: the previous test was with 4.8.1
[Bug c++/57765] [C++11] Variadic Template Specialization does not follow the INCITS/ISO/IEC 14882-2011 standard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57765
AaronNGray aaronngray.lists at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from AaronNGray aaronngray.lists at gmail dot com ---
If a template-parameter of a primary class template or alias template is a
template parameter pack, it shall be the last template-parameter.
template typename TR, typename ... Ts, TR (f)(Ts...) struct
OpFTR (Ts...), f { };
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834 --- Comment #11 from M.S. Babaei ace.of.zerosync at gmail dot com --- (In reply to James Kanze from comment #9) Re using the init list syntax: it won't work if you have to be compatible with other compilers (like Sun CC). Using something like (Doh (x)), ++x seems to be the most portable work-around. Of course I've already put some #ifdefs for GCC with init lists and rest of the compilers using the old good code.
[Bug c++/29834] g++ thinks it is a declaration when it cannot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834 --- Comment #12 from M.S. Babaei ace.of.zerosync at gmail dot com --- (In reply to Manuel López-Ibáñez from comment #10) (In reply to M.S. Babaei from comment #8) But this is a bug, and I see no reason why it hasn't been fixed anyway. I see plenty of reasons: It is a obscure bug, there are easy work-arounds, there are very few G++ developers (maybe 4-5 sporadic and two full-time? I am not even sure they are actually full-time...), and there are literally thousands of other bugs requiring attention. Any help would be welcome. Unfortunately I don't know C and do not understand how inner parts of GCC works. G++ is written in C++. The C++ FE is mostly isolated from other parts of the compiler and the parser is almost solely contained in gcc/cp/parser.c. If you know enough C++, you should be able to follow what it does. I am not saying it is pretty or easy, but it is doable. If you can use a debugger, you could figure out why g++ is getting confused here and what it should do instead. Thanks for the answer, I'll give it a shot.
[Bug c++/57746] Invalid specializations of member objects are accepted, unlike member functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-02 Ever confirmed|0 |1
[Bug tree-optimization/56982] [4.8 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 --- Comment #13 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30431 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30431action=edit another example of wrong compilation This is another example where the optimization can go wrong. The attached program produces expected results if compiled with -O0: x=0, a=1 x=1, a=1 a=1 But if compiled with -O3 and if the value a is placed in a register the result is like this: x=0, a=1 x=1, a=0 a=0 That is because longjmp has more semantic than just a branch: It branches to the setjmp, and restores all callee saved registers to the previos value.
[Bug tree-optimization/56982] [4.8 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 --- Comment #14 from Mikael Pettersson mikpe at it dot uu.se --- (In reply to Bernd Edlinger from comment #13) Created attachment 30431 [details] another example of wrong compilation This is another example where the optimization can go wrong. The attached program produces expected results if compiled with -O0: x=0, a=1 x=1, a=1 a=1 But if compiled with -O3 and if the value a is placed in a register the result is like this: x=0, a=1 x=1, a=0 a=0 That is because longjmp has more semantic than just a branch: It branches to the setjmp, and restores all callee saved registers to the previos value. Your example is invalid C. Referring to WG14 n1494.pdf (there may be more recent C1x documents, but it's the one I had available right now): - you violate 7.13.1.1 which specifies where setjmp() may be called, an assignment statement is not one of the permitted contexts - more importantly, your auto variable a is not volatile-qualified, which means that its value is indeterminate after the longjmp (7.13.2.1). Please fix these issues and check again if it yields wrong results.
[Bug regression/57766] [4.9 Regression]: gcc.sum c-c++-common/cilk-plus/AN/sec_implicit_ex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57766 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Looks like the same situation as PR57692.
[Bug target/57753] FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- Actually, FSF gcc doesn't know about the SDKROOT path that xcrun sets. A change similar to… http://permalink.gmane.org/gmane.comp.compilers.clang.scm/56103 needs to be implemented on darwin so that FSF checks for the SDKROOT environmental and uses it to find usr/include.
[Bug target/57792] New: --with-native-system-header-dir confuses -isysroot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 Bug ID: 57792 Summary: --with-native-system-header-dir confuses -isysroot Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu The removal of the SDK from / (i.e. no /usr/include or /System/Library/Frameworks/*.framework/Headers directories) breaks the fixincludes step of the bootstrap on darwin. The only current workaround appears to be using the --with-native-system-header-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/usr/include however this causes -isysroot in the resulting compiler to malfunction so that… /sw/lib/gcc4.8/bin/gcc-fsf-4.8 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk himenoBMTxpa.c searches… ignoring nonexistent directory /Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/usr/include Oddly executing the non-sensical… /sw/lib/gcc4.8/bin/gcc-fsf-4.8 -isysroot / himenoBMTxpa.c works because the search path becomes… /Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/usr/include I assume no one ever tested --with-native-system-header-dir with -ixysroot before.
[Bug c++/57793] New: Cross-Compiler Templates and Bitfields Ask to Report Problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793 Bug ID: 57793 Summary: Cross-Compiler Templates and Bitfields Ask to Report Problem Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ian at geometrian dot com Created attachment 30432 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30432action=edit Self-contained example of problem Compile attached example: i586-elf-gcc manager.cpp Output from attached example: manager.cpp: In member function 'void* Blockn::malloc(size_t) [with unsigned int n = 2147483648u; size_t = unsigned int]': manager.cpp:71:4: internal compiler error: in get_bit_range, at expr.c:4562 info.allocated = true; ^ 0x7036e6 get_bit_range ../../gcc-4.8.1/gcc/expr.c:4562 0x7036e6 expand_assignment(tree_node*, tree_node*, bool) ../../gcc-4.8.1/gcc/expr.c:4703 0x655532 expand_gimple_stmt_1 ../../gcc-4.8.1/gcc/cfgexpand.c:2208 0x655532 expand_gimple_stmt ../../gcc-4.8.1/gcc/cfgexpand.c:2304 0x656436 expand_gimple_basic_block ../../gcc-4.8.1/gcc/cfgexpand.c:4138 0x65831e gimple_expand_cfg ../../gcc-4.8.1/gcc/cfgexpand.c:4657 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. The example is being developed from a kernel, so some operations may look strange. However, the example is self-contained. Platform: Ubuntu 12.04 x86-64, all updated Compiler: Cross compiler as described here: http://wiki.osdev.org/GCC_Cross-Compiler for i586-elf. Compiled for x86. Error does not occur with standard GCC (this may be because the standard GCC on the platform is x64-64).
[Bug c++/57794] New: using keyword for function alias doesn't work with plus suffix return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57794 Bug ID: 57794 Summary: using keyword for function alias doesn't work with plus suffix return type Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: littlekid87 at gmail dot com In gcc 4.8.1, The following doesn't seems to work: using to_lower_fn_ptr = [](input_base_type, const std::locale) - input_base_type; When compile it gives the following error: error: expected type-specifier before '[' token using to_lower_fn_ptr = [](input_base_type, const std::locale) - input_base_type;
[Bug regression/57766] [4.9 Regression]: gcc.sum c-c++-common/cilk-plus/AN/sec_implicit_ex.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57766 Balaji V. Iyer bviyer at gmail dot com changed: What|Removed |Added CC||bviyer at gmail dot com --- Comment #2 from Balaji V. Iyer bviyer at gmail dot com --- This issue should be fixed in SVN revision 200581. Thanks, Balaji V. Iyer.
