[Bug fortran/55591] strict-aliasing & Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 --- Comment #5 from Joost VandeVondele 2013-03-29 06:13:38 UTC --- (In reply to comment #3) > Untested (but successfully compiled) patch: > > --- a/gcc/fortran/options.c > +++ b/gcc/fortran/options.c > @@ -170,4 +170,6 @@ gfc_init_options (unsigned int decoded_options_count, >set_default_std_flags (); > > + flag_strict_aliasing = -1; > + >/* Initialize cpp-related options. */ >gfc_cpp_init_options (decoded_options_count, decoded_options); > @@ -275,4 +277,8 @@ gfc_post_options (const char **pfilename) > gfc_option.flag_whole_file = 1; > > + /* By default use strict-aliasing semantics. */ > + if (flag_strict_aliasing == -1) > +flag_strict_aliasing = 1; > + >/* Fortran allows associative math - but we cannot reassociate if > we want traps or signed zeros. Cf. also flag_protect_parens. */ what about applying this to stage 1 4.9 ?
[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726 --- Comment #6 from Chip Salzenberg 2013-03-29 06:05:19 UTC --- May I have this accepted?
[Bug lto/56775] New: -flto and -fprofile-generate together result in a link-time internal compiler error (in "add_symbol_to_partition")
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56775 Bug #: 56775 Summary: -flto and -fprofile-generate together result in a link-time internal compiler error (in "add_symbol_to_partition") Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@gnu.org If I compile my program with _both_ options "-flto" and "-fprofile-generate", I get a link-time compile error. Using either "-flto" or "-fprofile-generate" _separately_ seems to work correctly. Compiler version is: g++ (Debian 20130316-1) 4.8.0 20130316 (experimental) [trunk revision 196694] I'm not exactly sure how to cut this down...trivial test cases don't seem to have the same problem. A transcript of the final link (the options passed when compiling each object file are similar, minus libraries etc): % make V=1 EXTRA_COMPILE_FLAGS=-fprofile-generate make all-am make[1]: Entering directory `/home/miles/src/snogray/snogray' g++-snapshot -O3 -fomit-frame-pointer -flto -ffast-math -march=native -mfpmath=sse -g -std=c++11 -Wall -Wextra -Winit-self -Wdouble-promotion -pedantic-errors -Wno-long-long -fprofile-generate -fno-finite-math-only -ftrapping-math -fno-associative-math -ffunction-sections -pthread -Wl,--icf=all -o snogray snogray.o recover-image.o libsnoglua.a libsnograw.a liblpeg.a -L/usr//lib -lluajit-5.1 libsnogrdrive.a libsnogloaders.a -l3ds libsnogmat.a libsnogsurf.a libsnoglight.a libsnogrender.a libsnogtex.a libsnogspace.a libsnogscene.a libsnogimagecli.a libsnogimage.a -lpng12 -pthread -lIlmImf -lz -lImath -lHalf -lIex -lIlmThread -ljpeg -lnetpbm libsnogcolor.a libsnogcli.a libsnogutil.a lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. lto-wrapper: g++ returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[1]: *** [snogray] Error 1 make[1]: Leaving directory `/home/miles/src/snogray/snogray' make: *** [all] Error 2
[Bug other/56755] Global symbol demangling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56755 --- Comment #3 from bryan 2013-03-29 02:32:20 UTC --- let me provide more details about this bug. I got all of my program's function names from compiler and wanted to demangle them. C++filt successfully demangled almost all of the names, except for the ones started with _GLOBAL. One example is the one I posted above. > c++filt _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE
[Bug c++/56772] placement new operator does not work inside function template for array types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56772 --- Comment #2 from meng at g dot clemson.edu 2013-03-29 00:45:23 UTC --- (In reply to comment #1) > I see a sorry message thus the issue seems known. I agree. What confused me was that the feature is not unimplemented, it worked well for ordinary functions. I wonder what makes function templates a special exception in this case.
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #13 from Michel Morin 2013-03-29 00:40:59 UTC --- Thanks Jason, Paolo. I'll enable N3276 decltype support in Boost.Config for gcc 4.8.1 and 4.9.0.
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774
--- Comment #4 from Shane 2013-03-29 00:21:32
UTC ---
(In reply to comment #1)
> We badly need a reduced testcase not using the whole (not to mention
> of course)
Here's a more reduced test case.
template
struct mytype {};
template
void something( mytype )
{ }
int main()
{
// Compiles OK in GCC 4.6.3 but NOT 4.8
something( mytype() );
// Compiles OK in GCC 4.8 but NOT 4.6.3
something( mytype() );
return 0;
}
I tried to make simpler cases using purely variadic templates (e.g. no class
T), but the issue only shows up when there is an individually named template
parameter as well as a variadic pack. To get the error to show up it also
requires types that cannot be implicitly converted to each other.
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Paolo Carlini 2013-03-29 00:17:49 UTC --- Thanks a lot Daniel. Let's CC Jason.
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774
Daniel Frey changed:
What|Removed |Added
CC||d.frey at gmx dot de
--- Comment #2 from Daniel Frey 2013-03-29 00:09:10 UTC
---
Here's a reduced testcase without any includes:
template< typename... > struct tuple {};
template< typename T, typename... Ts >
void f( tuple< T, Ts... >& ) {}
int main()
{
tuple< int, bool, char > t;
f< int, char, bool >(t);
}
This compiles with GCC 4.7.2 and GCC 4.8.0, but it shouldn't.
GCC 4.6.3 and Clang 3.2 reject the code as expected.
Output from GCC 4.6.3:
Compilation finished with errors:
source.cpp: In function 'int main()':
source.cpp:9:26: error: no matching function for call to 'f(tuple&)'
source.cpp:9:26: note: candidate is:
source.cpp:4:6: note: template void f(tuple&)
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #17 from Paolo Carlini 2013-03-28 23:58:04 UTC --- I see.
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-28 Summary|G++ 4.8 reverses variadic |[4.7/4.8/4.9 Regression] |template types during |G++ 4.8 reverses variadic |unpacking |template types during ||unpacking Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2013-03-28 23:57:30 UTC --- We badly need a reduced testcase not using the whole (not to mention of course)
[Bug c++/56772] placement new operator does not work inside function template for array types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56772 Paolo Carlini changed: What|Removed |Added CC|meng at g dot clemson.edu | --- Comment #1 from Paolo Carlini 2013-03-28 23:43:23 UTC --- I see a sorry message thus the issue seems known.
[Bug c++/56728] [4.8/4.9 Regression] ICE using constexpr initialization and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56728 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Jason Merrill 2013-03-28 23:41:18 UTC --- Fixed for 4.8.1.
[Bug fortran/45159] Unnecessary temporaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45159 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #29 from Thomas Koenig 2013-03-28 23:28:01 UTC --- I think we can close this bug with http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00846.html It's been around for some time, if somebody finds anything else, let us open a fresh one :-)
[Bug fortran/55806] Missed optimization with ANY or ALL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55806 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Thomas Koenig 2013-03-28 23:25:29 UTC --- Fixed with http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00845.html, closing.
[Bug middle-end/41115] Tree-vectorizer: VecCost tuning for X2: Without vectorization 30% faster
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41115 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus 2013-03-28 23:08:00 UTC --- (In reply to comment #3) > It would be nice to see where we are today with respect to the cost model / > vectorizing / not vectorizing. Answer: It became much worse (compared to GCC 4.5 of comment 0): Using gcc version 4.8.0 20130308 [trunk revision 196547], the induct runtimes are: gfortran -march=native -ffast-math -O3 -ftree-vectorize -fvect-cost-model induct.f90 real0m47.142s / user0m47.072s / sys 0m0.020s gfortran-4.8 -march=native -ffast-math -O3 -ftree-vectorize -fno-vect-cost-model induct.f90 real0m35.713s / user0m35.236s / sys 0m0.052s time gfortran-4.8 -march=native -ffast-math -O3 -fno-tree-vectorize induct.f90 real0m47.837s / user0m47.388s / sys 0m0.028s real0m47.514s / user0m47.428s / sys 0m0.044s gfortran -march=opteron -ffast-math -funroll-loops -fno-tree-vectorize -ftree-loop-linear -msse3 -O3 induct.f90 real0m44.676s / user0m44.640s / sys 0m0.032s gfortran-4.5 -march=opteron -ffast-math -funroll-loops -fno-tree-vectorize -ftree-loop-linear -msse3 -O3 induct.f90; time ./a.out real0m34.591s / user0m34.524s / sys 0m0.020s
[Bug fortran/56765] [OOP] compilation errors/ICE with unlimited polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2013-03-28 22:37:08 UTC --- Regarding the rank error (and "expr->rank = "), it seems as if one has to review the following functions in result.c: resolve_generic_f0, expression_rank, check_host_association, resolve_unknown_f, resolve_specific_f0, resolve_compcall,resolve_expr_ppc, resolve_assoc_var, add_comp_ref, resolve_structure_cons.
[Bug gcov-profile/56773] Programs crash if compiled with --coverage, although they run correctly without --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56773 peter.hans.froehlich at gmail dot com changed: What|Removed |Added CC||peter.hans.froehlich at ||gmail dot com --- Comment #2 from peter.hans.froehlich at gmail dot com 2013-03-28 21:48:36 UTC --- I agree that open is used by the standard library for a system call. The strange this is that in 4.2 this problem doesn't seem to occur. In 4.6 and 4.7 it does. Sorry, didn't have time to dig out more old GCC versions.
[Bug c++/56774] New: G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774
Bug #: 56774
Summary: G++ 4.8 reverses variadic template types during
unpacking
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: w.shane.gr...@gmail.com
In g++ 4.8, it seems as if variadic templates are reversed when being unpacked.
Consider the following minimal example:
#include
#include
template
void something( std::tuple & tup )
{
std::cout << std::get<1>(tup) << std::endl;
}
int main()
{
std::tuple myTuple(3, 'a', true);
// Compiles OK in GCC 4.6.3 but NOT 4.8
something( myTuple );
// Compiles OK in GCC 4.8 but NOT 4.6.3
something( myTuple );
return 0;
}
The output of this, if the appropriate line is commented out, will be: 'a'. To
get code that previously worked under 4.6.3, the template parameters that will
be unpacked have to be reversed.
See relevant Stack Overflow post here:
http://stackoverflow.com/questions/15692112/gcc-4-8-is-reversing-variadic-template-parameter-pack
[Bug gcov-profile/56773] Programs crash if compiled with --coverage, although they run correctly without --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56773 --- Comment #1 from Andrew Pinski 2013-03-28 21:14:28 UTC --- open is the name of the standard C function open. --coverage uses a library which calls the open function; this causes the crash. I think you are exposing undefined behavior.
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #16 from Jakub Jelinek 2013-03-28 21:13:15 UTC --- It isn't a library issue, in libstdc++ it is just ICE internal compiler error: in sra_ipa_reset_debug_stmts, at tree-sra.c:4681 in all the libstdc++ testcases that regressed because of these 3 patches, and in libgomp verifier ICEs. So supposedly something needs to be fixed in SRA and something in omp-low.c for these MEM_REF clobbers.
[Bug gcov-profile/56773] New: Programs crash if compiled with --coverage, although they run correctly without --coverage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56773
Bug #: 56773
Summary: Programs crash if compiled with --coverage, although
they run correctly without --coverage
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: shavitmichael+...@gmail.com
Compiling a C program with the --coverage option causes the program to crash
when run if the program has a global variable named "open".
Indeed declaring a variable "open" causes an Illegal instruction (core dumped),
and initializing it causes a Segmentation fault.
Example code:
*
#include
int open = 1;
int main(void) {
puts(“run”);
}
*
Compiling this code with -O0 --coverage, and running the program outputs:
run
Segmentation fault (core dumped)
However, if I remove the --coverage flag, or change the name of the variable
"open", the program runs just fine.
It looks like the gcov code tries to call a function called open, but ends up
calling the variable open.
Furthermore this doesn't seem to be an issue in version 4.2, however I haven’t
been able to verify for other version between 4.2 and 4.7.2.
More specifically, my gcc version is 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
[Bug c++/56772] New: placement new operator does not work inside function template.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56772
Bug #: 56772
Summary: placement new operator does not work inside function
template.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@g.clemson.edu
g++-4.7.0 emits an error for the following piece of code.
- BEGIN -
#include
#include
template
void f ()
{
size_t coord [2][2];
new (&coord) size_t [2][2]
{
{0,0},
{0,0},
};
}
int main ()
{
f<>();
}
- END -
The error message was
error: parenthesized initializer in array new [-fpermissive]
sorry, unimplemented: cannot initialize multi-dimensional array with
initializer
I observed the same behavior on 4.8.0. The problem only occurs inside function
template according to my test. If I made f an ordinary function, the code was
accepted. Clang 3.2 and Visual Studio 2012 all accept the code. These facts led
me to assume this is a bug in g++.
Below is my g++ version.
Reading specs from
/home/meng/gcc/4.7.0/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/specs
COLLECT_GCC=/home/meng/gcc/4.7.0/bin/c++
COLLECT_LTO_WRAPPER=/home/meng/gcc/4.7.0/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/meng/gcc/4.7.0
--enable-languages=c,c++ -disable-multilib
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug c++/56679] [C++11] Cannot take sizeof... a template template parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56679 --- Comment #2 from Paolo Carlini 2013-03-28 20:13:17 UTC --- Indeed. Thanks again!
[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 --- Comment #2 from Joel Sherrill 2013-03-28 20:12:06 UTC --- Created attachment 29748 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29748 Full build log In case there is something useful in the build log. Host: CentOS 6.4. FYI We first saw this back in Oct 2012. But could not reproduce it on another machine. I believe it has now been reproduced on 32-bit CentOS and Ubuntu hosts.
[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 --- Comment #1 from Joel Sherrill 2013-03-28 20:10:34 UTC --- Created attachment 29747 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29747 Preprocessed code that fails to build I don't think this code is in error. At least I don't see how. I think something has gone wrong with the arm cross-compiler being used to build it.
[Bug target/56771] New: Integer Overflow? Building arm-rtems libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 Bug #: 56771 Summary: Integer Overflow? Building arm-rtems libgcc2 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@gcc.gnu.org This error occurs on some hosts. We suspect it occurs only on 32-bit hosts. It appears that some magic is occurring where a constant is too large. Host: CentOS 6.4 32-bit Host GCC: 4.4.7 20120313 (Red Hat 4.4.7-3) Target: arm-rtems4.11 Component Versions: gcc-4.7.2 gmp-5.0.5 mpc-0.8.2 mpfr-3.0.1 newlib-2.0.0 Configure command: ../gcc-4.7.2/configure \ --prefix=/home/joel/rtems-4.11-work/tools \ --bindir=/home/joel/rtems-4.11-work/tools/bin \ --exec_prefix=/home/joel/rtems-4.11-work/tools \ --includedir=/home/joel/rtems-4.11-work/tools/include \ --libdir=/home/joel/rtems-4.11-work/tools/lib \ --libexecdir=/home/joel/rtems-4.11-work/tools/libexec \ --mandir=/home/joel/rtems-4.11-work/tools/share/man \ --infodir=/home/joel/rtems-4.11-work/tools/share/info \ --datadir=/home/joel/rtems-4.11-work/tools/share \ --build=i686-linux-gnu --host=i686-linux-gnu \ --target=arm-rtems4.11 \ --disable-libstdcxx-pch \ --with-gnu-as --with-gnu-ld --verbose \ --with-newlib \ --with-system-zlib \ --disable-nls --without-included-gettext \ --disable-win32-registry \ --enable-version-specific-runtime-libs \ --disable-lto \ --enable-threads \ --disable-plugin \ --enable-newlib-io-c99-formats \ --enable-newlib-iconv \ --enable-obsolete \ --enable-languages="$languages" Failure output: /home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2-1/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2/build/./gcc/xgcc -B/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2-1/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2/build/./gcc/ -nostdinc -B/home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2-1/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2/build/arm-rtems4.11/newlib/ -isystem /home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2-1/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2/build/arm-rtems4.11/newlib/targ-include -isystem /home/joel/rtems-4.11-work/rtems-source-builder/rtems/build/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2-1/arm-rtems4.11-gcc-4.7.2-newlib-2.0.0-1-4.7.2/gcc-4.7.2/newlib/libc/include -B/home/joel/rtems-4.11-work/tools/arm-rtems4.11/bin/ -B/home/joel/rtems-4.11-work/tools/arm-rtems4.11/lib/ -isystem /home/joel/rtems-4.11-work/tools/arm-rtems4.11/include -isystem /home/joel/rtems-4.11-work/tools/arm-rtems4.11/sys-include-g -O2 -mthumb -O2 -I../../../../gcc-4.7.2/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../../.././gcc -I../../../../gcc-4.7.2/libgcc -I../../../../gcc-4.7.2/libgcc/. -I../../../../gcc-4.7.2/libgcc/../gcc -I../../../../gcc-4.7.2/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c ../../../../gcc-4.7.2/libgcc/libgcc2.c In file included from ../../../../gcc-4.7.2/libgcc/libgcc2.c:30:0: ../../../../gcc-4.7.2/libgcc/../gcc/coretypes.h:188:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] ../../../../gcc-4.7.2/libgcc/../gcc/coretypes.h:195:1: warning: enumeration values exceed range of largest integer [enabled by default] In file included from ../../.././gcc/options.h:6:0, from ../../.././gcc/tm.h:14, from ../../../../gcc-4.7.2/libgcc/libgcc2.c:31: ../../../../gcc-4.7.2/libgcc/../gcc/flag-types.h:139:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] ../../../../gcc-4.7.2/libgcc/../gcc/flag-types.h:147:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] ../../../../gcc-4.7.2/libgcc/../gcc/flag-types.h:186:1: warning: enumeration values exceed range of largest integer [enabled by default] ../../../../gcc-4.7.2/libgcc/../gcc/flag-types.h:190:3: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] ../../../../gcc-4.7.2/libgcc/../gcc/flag-types.h:193:1: warning: enumeration values exceed range of largest integer [enabled by default] In file included from ../../.././gcc/options.h:8:0, from ../../.././gcc/tm.h:14, from ../../../../gcc-4.7.2/libgcc/libgcc2.c:31: ../../../../gcc-4.7.2/libgcc/../gcc/config/arm/
[Bug c++/56710] Using reserved double underscore variable name in a lambda causes internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56710 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.9.0 --- Comment #1 from Jason Merrill 2013-03-28 20:05:42 UTC --- Fixed for 4.9.
[Bug c++/56701] [C++11] The *this* pointer fails to bind to rvalue reference to pointer type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56701 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.9.0 --- Comment #2 from Jason Merrill 2013-03-28 20:05:11 UTC --- Fixed for 4.9.
[Bug c++/56679] [C++11] Cannot take sizeof... a template template parameter pack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56679 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.9.0 --- Comment #1 from Jason Merrill 2013-03-28 20:04:12 UTC --- Fixed for 4.9.
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 Jason Merrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from Jason Merrill 2013-03-28 20:02:57 UTC --- Fixed again. I added a different testcase whose failure mode is an error, rather than consuming all resources.
[Bug tree-optimization/56770] New: Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770
Bug #: 56770
Summary: Partial sums loop optimization
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
GCC loop optimization should unroll and transform loops using partial sums
where beneficial for expensive, independent computations where the target has
additional function units available.
Before
double fValue = 0;
int j;
for (j = 0; j < NZ; j++)
fValue += Q[j] / r[j];
After
double fValue = 0;
double fValue1 = 0;
int j;
for (j = 0; j < NZ; j=j+2){
fValue += Q[j] / r[j];
fValue1 += Q[j+1] / r[j+1];
}
for (j = (NZ/2)*2; j < NZ; j++){
fValue += Q[j] / r[j];
}
fValue = fValue + fValue1;
[Bug libstdc++/53631] [C++11] is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez 2013-03-28 19:21:57 UTC --- (In reply to comment #5) > Why is the priority just normal? I think its very much needed. I wish there > was > a vote button for the issues. A vote button would be useless. What gets implemented does not depend on votes or wishes, but in someone *really* thinking that it is so needed that they are willing to implement it themselves or pay someone to implement it.
[Bug c++/56769] New: [4.7] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56769
Bug #: 56769
Summary: [4.7] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:2511
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Probably related to PR 56768
Google ref b/8485258
Does *not* reproduce on trunk
Does reproduce using gcc-4_7 (r197167)
Test case:
struct Iter
{
int& operator* ();
void operator++ ();
};
bool operator!= (Iter &, Iter &) { }
struct Container
{
Iter begin () const;
Iter end () const;
};
struct J
{
virtual J *mutable_child ();
};
struct M
{
M (const Container &);
J ns_;
};
namespace
{
J MakeNamespace (const Container &src)
{
J a;
J *b = 0;
for (const int &c: src)
b = b ? b->mutable_child () : &a;
return a;
}
}
M::M (const Container &ns):ns_ (MakeNamespace (ns))
{
}
Note: the only difference from test case in PR 56768 is:
diff pp.ii pp2.ii
7c7
< bool operator!= (Iter &, Iter &);
---
> bool operator!= (Iter &, Iter &) { }
cc1plus pp2.ii -std=c++11 -quiet && echo ok
ok
cc1plus pp2.ii -std=c++11 -quiet -O2
pp2.ii: In constructor ‘M::M(const Container&)’:
pp2.ii:36:1: internal compiler error: in set_ssa_val_to, at
tree-ssa-sccvn.c:2511
Please submit a full bug report,
[Bug fortran/56765] [OOP] compilation errors/ICE with unlimited polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2013-03-28 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|compilation errors/ICE with |[OOP] compilation |unlimited polymorphic array |errors/ICE with unlimited ||polymorphic array --- Comment #1 from janus at gcc dot gnu.org 2013-03-28 18:43:31 UTC --- Confirmed with current trunk.
[Bug c++/56768] New: [4.7] ICE in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56768
Bug #: 56768
Summary: [4.7] ICE in make_decl_rtl, at varasm.c:1147
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref b/8485258
Does *not* reproduce on trunk
Does reproduce using gcc-4_7 (r197167)
Test case:
struct Iter
{
int& operator* ();
void operator++ ();
};
bool operator!= (Iter &, Iter &);
struct Container
{
Iter begin () const;
Iter end () const;
};
struct J
{
virtual J *mutable_child ();
};
struct M
{
M (const Container &);
J ns_;
};
namespace
{
J MakeNamespace (const Container &src)
{
J a;
J *b = 0;
for (const int &c: src)
b = b ? b->mutable_child () : &a;
return a;
}
}
M::M (const Container &ns):ns_ (MakeNamespace (ns))
{
}
cc1plus pp.ii -std=c++11 -quiet && echo ok
ok
cc1plus pp.ii -std=c++11 -quiet -O2
pp.ii: In constructor ‘M::M(const Container&)’:
pp.ii:36:1: internal compiler error: in make_decl_rtl, at varasm.c:1147
Please submit a full bug report,
[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #2 from Jack Howarth 2013-03-28 17:47:41 UTC --- This issue blocks building dragonegg svn against FSF gcc 4.8.0... c++ -c -I/sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/include/x86 -I/sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/include/darwin -g -DENABLE_BUILD_WITH_CXX -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.3/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -MD -MP -DIN_GCC -DLLVM_VERSION=\"3.3svn\" -DTARGET_TRIPLE=\"x86_64-apple-darwin12.3.0\" -DGCC_MAJOR=4 -DGCC_MINOR=8 -DGCC_MICRO=0 -I/sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/include -isystem/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0/plugin/include -Wall -Wextra -DENABLE_LLVM_PLUGINS -I/sw/opt/llvm-3.3/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wnon-virtual-dtor -O3 -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/src/Backend.cpp /sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/src/Backend.cpp:83:10: fatal error: 'target.h' file not found #include "target.h" // For targetm. ^ 1 error generated.
[Bug c/56767] gcc does not generate correct code with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56767 --- Comment #2 from Jonathan Wakely 2013-03-28 17:39:38 UTC --- GCC clearly warns you about this: x.c: In function ‘round2’: x.c:10:1: warning: control reaches end of non-void function [-Wreturn-type] This is why before creating the bug report you were told: "Before reporting that GCC compiles your code incorrectly, compile it with gcc -Wall -Wextra and see whether this shows anything wrong with your code."
[Bug c/56767] gcc does not generate correct code with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56767 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2013-03-28 17:35:29 UTC --- ret = 1 << ret; } you never do a "return ret;"
[Bug c/56767] New: gcc does not generate correct code with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56767
Bug #: 56767
Summary: gcc does not generate correct code with -O2
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jupitercu...@gmail.com
== How to repeat (on a 32-bit Linux machine) ==
With following code:
// begin of code
#include
int round2(int n) {
int ret;
if (n == 0) { return 0; }
__asm__ __volatile__ ("bsr %0, %1\n\t"
:"=r"(ret): "r"(n));
ret = 1 << ret;
}
int main() {
int a;
scanf("%d", &a);
printf("%d\n", round2(a));
return 0;
}
// end of code
With -O0, we get correct result, but with -O2, the generated assembly is:
main:
.LFB12:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
andl$-16, %esp
subl$32, %esp
leal28(%esp), %eax
movl%eax, 4(%esp)
movl$.LC0, (%esp)
call__isoc99_scanf
movl28(%esp), %eax
testl %eax, %eax
je .L6
#APP
# 6 "bit.c" 1
bsr %eax, %eax
# 0 "" 2
#NO_APP
.L6:
movl$0, 4(%esp) // ALWAYS output 0
movl$.LC1, (%esp)
callprintf
xorl%eax, %eax
leave
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760
--- Comment #11 from Jonathan Wakely 2013-03-28
17:19:06 UTC ---
(In reply to comment #10)
> But the function actually IS defined,
No it isn't! Please read my answer again carefully.
The function that gets called is
template void func (const T &a, nam::binbuffer &b);
and NOT
template void func(const seco::holder &a, nam::binbuffer &b)
{ func(*a.fun, b); }
These are not the same function, and the first one is NOT defined.
> because the call func(foo,b) works.
That comes *after* the relevant function is defined, so name lookup finds it.
> Yes
> it is not defined early enough maybe. But the linker is run after the
> compiler.
Irrelevant. The call to func(*a.wombat, b) finds a function template that is
not defined. The compiler generates a reference to a particular function, the
linker can't decide to link it to a different function just because you think
they're similar.
> How can the linker differentiate about when something is implemented? doesn't
> it just look for the symbol and if it is there, then it is there?
Because the call doesn't use the function you think it does!
> as mentioned in my post 2013-03-28 08:27:34 UTC the signature of the missing
> implementation is exactly the same in the error message if you leave out the
> template definition than if you do the line that you call invalid C++.
No, they are *not* the same, try using 'nm' to see they are different symbols:
U _Unwind_Resume
W
_Z4funcIN4seco6holderIiEEEvRKNS0_7containIT_EERN3nam9binbufferE
U _Z4funcIN4seco6holderIiEEEvRKT_RN3nam9binbufferE
W _Z4funcIiEvRKN4seco6holderIT_EERN3nam9binbufferE
T _Z4funcIiEvRKT_RN3nam9binbufferE
U __gxx_personality_v0
000e T main
The missing definition is
U _Z4funcIN4seco6holderIiEEEvRKT_RN3nam9binbufferE
and the defined one is:
W _Z4funcIiEvRKN4seco6holderIT_EERN3nam9binbufferE
THESE ARE NOT THE SAME SYMBOL!
Demangled, the names are:
U void func >(seco::holder const&,
nam::binbuffer&)
W void func(seco::holder const&, nam::binbuffer&)
THESE ARE NOT THE SAME SYMBOL!
> So maybe the linker output should show more detail. The linker sais that an
> implementation is missing, which is NOT missing.
You're wrong. Look at the symbols.
> so maybe there is some
> additional clue that the linker could display here? is there some hidden
> additional information in the function signature somehow?
It's not hidden, it's right there in the signature but you're refusing to read
it:
x.C:11: undefined reference to
`void func >(seco::holder const&, nam::binbuffer&)'
^
Look at the template argument list. Are you sure you defined it?
Look at the symbols again, with whitespace added to help:
U void func >(seco::holder const&, nam::binbuffer&)
W void func (seco::holder const&, nam::binbuffer&)
Can you see what's different yet?
> the section about name lookup changes talks about the -fpermissive option
> which
> should reactivate the old behaviour. but that does not work.
I didn't say -fpermissive would work, but the text describes how name lookup
only finds names that are visible at the point of definition, or can be found
by ADL at the point of instantiation.
> anyway... what could be a workaround? as mentioned earlier I cannot do a
> forward declaration.
It's not GCC's job or my job to fix your code, please try somewhere more
suitable like stackoverflow.com
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 --- Comment #10 from erik.thi...@thiele-hydraulik.de 2013-03-28 16:50:06 UTC --- But the function actually IS defined, because the call func(foo,b) works. Yes it is not defined early enough maybe. But the linker is run after the compiler. How can the linker differentiate about when something is implemented? doesn't it just look for the symbol and if it is there, then it is there? as mentioned in my post 2013-03-28 08:27:34 UTC the signature of the missing implementation is exactly the same in the error message if you leave out the template definition than if you do the line that you call invalid C++. So maybe the linker output should show more detail. The linker sais that an implementation is missing, which is NOT missing. so maybe there is some additional clue that the linker could display here? is there some hidden additional information in the function signature somehow? the section about name lookup changes talks about the -fpermissive option which should reactivate the old behaviour. but that does not work. anyway... what could be a workaround? as mentioned earlier I cannot do a forward declaration. This really puzzles me...
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #15 from Paolo Carlini 2013-03-28 16:11:31 UTC --- Cool, thanks guys for working on this. I hope the library issues aren't too serious.
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #13 from Paolo Carlini 2013-03-28 16:06:41 UTC --- Fixed for 4.9.0.
[Bug libstdc++/53631] [C++11] is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Balakrishnan B changed: What|Removed |Added CC||balakrishnan.erode at gmail ||dot com --- Comment #5 from Balakrishnan B 2013-03-28 15:17:16 UTC --- Why is the priority just normal? I think its very much needed. I wish there was a vote button for the issues.
[Bug c++/15672] local function causes weird warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15672 Jonathan Wakely changed: What|Removed |Added CC||npl at chello dot at --- Comment #17 from Jonathan Wakely 2013-03-28 15:14:11 UTC --- *** Bug 56762 has been marked as a duplicate of this bug. ***
[Bug c++/56762] too aggressive optimization or missing warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56762 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Jonathan Wakely 2013-03-28 15:14:11 UTC --- We should give a warning, see PR 15672 *** This bug has been marked as a duplicate of bug 15672 ***
[Bug c++/15672] local function causes weird warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15672 --- Comment #16 from Jonathan Wakely 2013-03-28 15:13:08 UTC --- Clang diagnoses the most vexing parse, comment 5 gets: sf.cc:7:7: warning: parentheses were disambiguated as a function declaration [-Wvexing-parse] g1 f(t(c)); ^~~ sf.cc:7:8: note: add a pair of parentheses to declare a variable g1 f(t(c)); ^ ()
[Bug rtl-optimization/56766] New: Fails to combine (vec_select (vec_concat ...)) to (vec_merge ...)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56766
Bug #: 56766
Summary: Fails to combine (vec_select (vec_concat ...)) to
(vec_merge ...)
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: r...@gcc.gnu.org
Target: x86_64-*-*
With a patch to vectorize the pattern that should lead to the use of
(define_insn "sse3_addsubv2df3"
[(set (match_operand:V2DF 0 "register_operand" "=x,x")
(vec_merge:V2DF
(plus:V2DF
(match_operand:V2DF 1 "register_operand" "0,x")
(match_operand:V2DF 2 "nonimmediate_operand" "xm,xm"))
(minus:V2DF (match_dup 1) (match_dup 2))
(const_int 2)))]
"TARGET_SSE3"
this instruction fails to be generated because the GIMPLE
vect_var_.9_15 = vect_var_.5_22 + vect_var_.8_18;
vect_var_.10_14 = vect_var_.5_22 - vect_var_.8_18;
_2 = VEC_PERM_EXPR ;
is expanded to
(insn 24 23 25 (set (reg:V2DF 80 [ vect_var_.9 ])
(plus:V2DF (reg:V2DF 76 [ vect_var_.5 ])
(reg:V2DF 75 [ vect_var_.8 ]))) t.c:7 -1
(nil))
(insn 25 24 27 (set (reg:V2DF 81 [ vect_var_.10 ])
(minus:V2DF (reg:V2DF 76 [ vect_var_.5 ])
(reg:V2DF 75 [ vect_var_.8 ]))) t.c:7 -1
(nil))
(insn 27 25 28 (set (reg:V2DF 82 [ D.1768 ])
(vec_select:V2DF (vec_concat:V4DF (reg:V2DF 80 [ vect_var_.9 ])
(reg:V2DF 81 [ vect_var_.10 ]))
(parallel [
(const_int 0 [0])
(const_int 3 [0x3])
]))) t.c:7 -1
(nil))
which does not match the pattern in the i386 backend.
The question is what should be the canonical form? Definitely vec_merge
is redundant and can always be replaced with (vec_select (vec_concat ...)).
Testcase w/o my vectorizer hack (compile with -O -msse3):
typedef double v2df __attribute__((vector_size(16)));
typedef long long v2di __attribute__((vector_size(16)));
v2df foo (v2df x, v2df y)
{
v2df tem1 = x + y;
v2df tem2 = x - y;
return __builtin_shuffle (tem1, tem2, (v2di) { 0, 3 });
}
VEC_MERGE is not used very often ...
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #14 from Jakub Jelinek 2013-03-28 14:09:01 UTC --- Created attachment 29746 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29746 gcc49-pr34949-2.patch Another needed patch, without which DSE wouldn't really delete the unneeded stores.
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949 --- Comment #13 from Jakub Jelinek 2013-03-28 14:07:42 UTC --- Created attachment 29745 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29745 gcc49-pr34949-1.patch Incremental patch, passed bootstrap together with the later jason's patch plus another one I'm going to attach. There are some testsuite regressions (a couple of them in libgomp testsuite, couple of them in libstdc++ testsuite) to be looked at though.
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #11 from Paolo Carlini 2013-03-28 13:46:02 UTC --- Thanks Jason. Looks like to be safe we should also add Nathan's testcase as-is to the testsuite.
[Bug fortran/56765] New: compilation errors/ICE with unlimited polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 Bug #: 56765 Summary: compilation errors/ICE with unlimited polymorphic array Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: escou...@gmail.com When compiling following program: program t_unlimited_2 implicit none class(*), dimension(:), pointer :: u u => sub() contains function sub() result(r) class(*), dimension(:), pointer :: r integer, dimension(3), target :: x = [1,2,3] r => x end function end program I get the output: -- $gfortran -Wall -Wextra t_unlimited_2.f90 t_unlimited_2.f90:4.4: u => sub() 1 Error: Different ranks in pointer assignment at (1) - u and sub are both of rank 1. When compiling the following (u is scalar here): program t_unlimited_3 implicit none class(*), pointer :: u u => sub() contains function sub() result(r) class(*), dimension(:), pointer :: r integer, dimension(3), target :: x = [1,2,3] r => x end function end program I get an ICE: $gfortran -Wall -Wextra t_unlimited_3.f90 t_unlimited_3.f90: In function ‘t_unlimited_3’: t_unlimited_3.f90:4:0: internal compiler error: in fold_convert_loc, at fold-const.c:1862 u => sub() ^ t_unlimited_3.f90:4:0: internal compiler error: Abort trap gfortran: internal compiler error: Abort trap (program f951) Abort trap - Version: $gfortran -v Using built-in specs. COLLECT_GCC=/xsw/gf48/bin/gfortran COLLECT_LTO_WRAPPER=/xsw/gcc-4.8-20130321/install/libexec/gcc/x86_64-apple-darwin10.8.0/4.8.0/lto-wrapper Target: x86_64-apple-darwin10.8.0 Configured with: ../src/configure --prefix=/xsw/gcc-4.8-20130321/install --enable-languages=c,fortran --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-libiconv-prefix=/opt/local Thread model: posix gcc version 4.8.0 20130321 (prerelease) (GCC) Running on Mac OS X 10.6.8
[Bug c++/56762] too aggressive optimization or missing warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56762 --- Comment #2 from npl at chello dot at 2013-03-28 13:38:01 UTC --- Oh how I hate this rule. Thanks for the info and sorry for the invalid report.
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 --- Comment #10 from Jason Merrill 2013-03-28 13:36:07 UTC --- The implementation is complete. Unfortunately, my fixes for DRs 337 and 657 are interfering with the desired result; creating a function type returning an abstract class causes deduction to fail, so we instantiate the return type of wrap in order to determine whether it is abstract. I guess I'll disable that instantiation and raise this issue with Core...
[Bug c++/52748] [4.9 Regression][C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748 Paolo Carlini changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[C++11] N3276 changes to|[4.9 Regression][C++11] |decltype|N3276 changes to decltype --- Comment #9 from Paolo Carlini 2013-03-28 13:29:00 UTC --- Jason is the right person to answer your first and third question, but the answer to the second one is simple: we have a regression in mainline, current 4_8-branch works fine.
[Bug fortran/52865] GCC can't vectorize fortran loop but able to vectorize similar c-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52865 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Richard Biener 2013-03-28 13:24:16 UTC --- Vectorized now.
[Bug tree-optimization/56764] vect_prune_runtime_alias_test_list not smart enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-28 Blocks||53947 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-03-28 13:15:28 UTC --- There is a dup for this bug. The whole alias test construction machinery needs to be re-written to support merging tests for adjacent DRs.
[Bug c++/52748] [C++11] N3276 changes to decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52748
Michel Morin changed:
What|Removed |Added
CC||mimomorin at gmail dot com
--- Comment #8 from Michel Morin 2013-03-28
13:11:00 UTC ---
The implementation of N3276 is not complete.
`decltype` in gcc-4.9-20130324 does not require type-completeness
but involves unnecessary template instantiations:
* Compilation of the demonstration code in N3276 (also appeared in
Nathan Ridge's comment in this PR) exhausted memory on my PC,
so I had to quit the compilation.
* Boost's testing code
(https://svn.boost.org/svn/boost/trunk/libs/config/test/boost_no_decltype_n3276.ipp)
failed to compile.
(One needs to remove `namespace boost_no_cxx11_decltype_n3276 {` and its
closing
brace`}`, and rename `int test()` to `int main()` before the compilation.)
[Bug tree-optimization/56764] New: vect_prune_runtime_alias_test_list not smart enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56764
Bug #: 56764
Summary: vect_prune_runtime_alias_test_list not smart enough
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
__attribute__((noinline, noclone)) void
foo (float x[3][32], float y1, float y2, float y3, float *z1, float *z2, float
*z3)
{
int i;
for (i = 0; i < 32; i++)
{
z1[i] = -y1 * x[0][i];
z2[i] = -y2 * x[1][i];
z3[i] = -y3 * x[2][i];
}
}
float x[6][32] __attribute__((aligned (32)));
int
main ()
{
int i;
for (i = 0; i < 32; i++)
{
x[0][i] = i;
x[1][i] = 7 * i;
x[2][i] = -5.5 * i;
}
for (i = 0; i < 1; i++)
foo (&x[0], 12.5, 0.5, -1.5, &x[3][0], &x[4][0], &x[5][0]);
return 0;
}
isn't vectorized on x86_64-linux with -O3 -mavx, because there are too many
versioning checks for alias. We vectorize it only with
--param vect-max-version-for-alias-checks=12 . But I don't see why we'd need
to emit that many checks for versioning, instead of the 12 checks for aliasing
we emit we could emit just 6 (keep the 3 overlap checks in between z1, z2 and
z3
and just merge each of the zN vs. &x[0][0], zN vs. &x[1][0] and zN vs. &x[2][0]
tests into one comparing zN[0] though zN[31] range with &x[0][0] through
&x[2][31]. Similarly, if we wanted to do a runtime check for alignment (not
the case on x86_64 apparently), we could test only alignment of &x[0][0],
because
it is provably the same alignment as &x[1][0] and &x[2][0].
[Bug c++/56763] New: "attribute ignored in declaration of " warning points to wrong place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56763
Bug #: 56763
Summary: "attribute ignored in declaration of " warning points
to wrong place
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kai.koe...@digia.com
When putting an attribute at the wrong place in a friends declaration, gcc does
point incorrectly to the actual class declaration. E.g.
--
class __attribute__((visibility("default"))) X {
};
class Y {
friend __attribute__((visibility("default"))) class X;
};
int main(int , char *[])
{
}
--
will print
--
./gccattributewarning/main.cpp:1:46: warning: attribute ignored in declaration
of 'class X' [-Wattributes]
class __attribute__((visibility("default"))) X {
^
../gccattributewarning/main.cpp:1:46: note: attribute for 'class X' must follow
the 'class' keyword
--
. What I would have expected is that it points to main.cpp:5 instead.
[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code Status|NEW |ASSIGNED CC||burnus at gcc dot gnu.org AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.4 --- Comment #6 from Tobias Burnus 2013-03-28 12:42:51 UTC --- See http://gcc.gnu.org/onlinedocs/gfortran/Extensions-to-namelist.html for the description of the ? and =? extension. Actually, there are two bugs: a) With "?", no attempt is made to read the next item. That's a bug due to Jerry's patch for PR 47154 (http://gcc.gnu.org/r168502). Here, '?' was falling through to a "goto find_nml_name;" - but no longer after "case EOF:" was added. b) With "?", there is no output. Seemingly, a regression due to Janne's patch for PR 25561 (http://gcc.gnu.org/r135373). Here, a "if (!p)" got lost.
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 --- Comment #9 from Richard Biener 2013-03-28 12:42:17 UTC --- Created attachment 29744 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29744 patch This patch makes us not rely on a dominator walk to magically get us process stmts in the correct order but instead uses the dependences we record for each stmt to make sure we moved them before uses. And fixes things to actually record all dependences (translating stmt to bb dependencies before that walk may speed up things for some testcases, processing in a good order from the start can avoid the recursion - processing stmts rather than BBs with a worklist is another possibility - we should be able to "drain" the depends vector into the worklist).
[Bug tree-optimization/55334] [4.8/4.9 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #31 from Martin Jambor 2013-03-28 12:36:36 UTC --- The 4.8 workaround has been reverted yesterday with the commit below so the bug should be alive and kicking again. Author: jamborm Date: Wed Mar 27 14:06:58 2013 New Revision: 197163 URL: http://gcc.gnu.org/viewcvs?rev=197163&root=gcc&view=rev Log: 2013-03-27 Martin Jambor PR tree-optimization/55334 * ipa-cp.c (initialize_node_lattices): Allow IPA-CP through and to restricted pointers to arrays. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756
--- Comment #8 from Richard Biener 2013-03-28
12:34:24 UTC ---
Ok, so one reason is that we simply "ignore" dependencies when computing
what stmts to move (which happens in the same processing order):
static bool
add_dependency (tree def, struct lim_aux_data *data, struct loop *loop,
bool add_cost)
{
...
max_loop = outermost_invariant_loop (def, loop);
if (!max_loop)
return false;
...
def_data = get_lim_data (def_stmt);
if (!def_data)
return true;
so, when we don't know anything about the stmt we depend on because we
didn't visit it yet outermost_invariant_loop returns garbage in this case.
But I got side-tracked by the above (which still should be fixed IMHO),
as also store-motion does not properly initialize dependence.
[Bug c++/56762] too aggressive optimization or missing warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56762 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2013-03-28 12:15:30 UTC --- This line does not what you expect it would do (Search for "most vexing parse"): CLockGuard sGuard(CIntLock()); It does *not* construct an CIntLock object nor does it declare an sGuard object, instead it does declare a function and has no further effects.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Marek Polacek 2013-03-28 11:15:35 UTC --- Fixed.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 --- Comment #13 from Marek Polacek 2013-03-28 11:15:20 UTC --- Author: mpolacek Date: Thu Mar 28 11:14:44 2013 New Revision: 197192 URL: http://gcc.gnu.org/viewcvs?rev=197192&root=gcc&view=rev Log: PR tree-optimization/56695 * tree-vect-stmts.c (vectorizable_condition): Unconditionally build signed result of a vector comparison. * tree-cfg.c (verify_gimple_comparison): Check that a result of a vector comparison has signed type. Added: trunk/gcc/testsuite/gcc.dg/vect/pr56695.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-vect-stmts.c
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760
--- Comment #9 from Jonathan Wakely 2013-03-28
11:05:26 UTC ---
(In reply to comment #8)
> I read the section on name lookup changes at
> http://gcc.gnu.org/gcc-4.7/porting_to.html
>
> but it talks about a different kind of problem. Consider that there the
> compiler does error messages. But here at our problem the linker (!) does the
> error.
It's the same problem. You get a linker error because this line:
func(containHolder, b); // COMMENT THIS OUT AND IT WORKS
calls this function:
template void func(const seco::contain &a, nam::binbuffer &b)
{ func(*a.wombat, b); }
which then calls this function:
template void func (const T &a, nam::binbuffer &b);
which is not defined. So you get a linker error.
You are expecting it to call this function:
template void func(const seco::holder &a, nam::binbuffer &b)
{ func(*a.fun, b); }
but it cannot, because that is not declared before it is used. This is the
situation described in the name lookup changes.
Your code is not valid C++, the compiler is correct.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #7 from Mathias Gaunard 2013-03-28 10:39:53 UTC --- Using either -save-temps or -ftrack-macro-expansion=0-ftrack-macro-expansion=0 removes the memory hog. Compiling the preprocessed source does not cause increased memory usage. So it seems the macro expansion tracking is what's causing a lot of extra memory usage here.
[Bug c++/56762] New: too aggressive optimization or missing warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56762 Bug #: 56762 Summary: too aggressive optimization or missing warnings Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: n...@chello.at Created attachment 29743 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29743 code describing the issue Alternatively this could be just me misunderstanding C++. But the issue is that I have an object created on the stack and I would expect it to survive until it goes out of scope. Now I understand that I probably used it the wrong way by giving it a temporary when it needed a reference to something more solid, but I would expect an error message in this case. Please look at the provided code, which compiles without error/warning. the exchange function wont have any calls to lock/unlock. tested with gcc 4.7.2 + 4.8.0
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 --- Comment #7 from rguenther at suse dot de 2013-03-28 10:26:48 UTC --- On Thu, 28 Mar 2013, mpolacek at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 > > --- Comment #6 from Marek Polacek 2013-03-28 > 10:11:55 UTC --- > FWIW, started with > http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=196769 Yes, I was expecting that. This orders blocks in a different "random" order when visiting dominator children. It tries to order them in inverted postorder - which is exactly deterministically "wrong" for LIM, as it visits loop blocks with a loop exit edge last.
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 --- Comment #6 from Marek Polacek 2013-03-28 10:11:55 UTC --- FWIW, started with http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=196769
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 --- Comment #5 from rguenther at suse dot de 2013-03-28 10:07:29 UTC --- On Thu, 28 Mar 2013, mpolacek at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 > > --- Comment #4 from Marek Polacek 2013-03-28 > 09:54:58 UTC --- > It seems that move_computations_stmt firstly inserts into bb 11 > # VUSE <.MEM_21> > D__lsm.5 = *_17; > and then > # VUSE <.MEM_21> > _17 = *q_8(D); > > move_computations then commits these inserts. LIM relies on dom-walk to walk blocks in a order that processes SSA definitions before uses. But that is not what a dom-walk guarantees ...
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 Tobias Burnus changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | --- Comment #4 from Tobias Burnus 2013-03-28 10:00:42 UTC --- (In reply to comment #3) > Note the comment at line 728 of format.c where we must disable format caching > when we encounter FMT_STRING. The problem is related to saving a pointer to a > string rather than the string itself. That pointer can go out of scope on > subsequent I/O operations so caching the format data will not work. Well, one could save the data. The string is also stored in the hash: u->format_hash_table[hash].key = xmalloc (dtp->format_len); memcpy (u->format_hash_table[hash].key, dtp->format, dtp->format_len); Thus, instead of saving it after the parsing as key, one can duplicate the string and store it as dtp->format before parsing the string. That's what I do in the patch, submitted at: http://gcc.gnu.org/ml/fortran/2013-03/msg00155.html
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 --- Comment #8 from erik.thi...@thiele-hydraulik.de 2013-03-28 09:55:49 UTC --- I read the section on name lookup changes at http://gcc.gnu.org/gcc-4.7/porting_to.html but it talks about a different kind of problem. Consider that there the compiler does error messages. But here at our problem the linker (!) does the error. also the mentioned -fpermissive flag does not change the situation.
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 --- Comment #4 from Marek Polacek 2013-03-28 09:54:58 UTC --- It seems that move_computations_stmt firstly inserts into bb 11 # VUSE <.MEM_21> D__lsm.5 = *_17; and then # VUSE <.MEM_21> _17 = *q_8(D); move_computations then commits these inserts.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 Richard Biener changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #6 from Richard Biener 2013-03-28 09:51:35 UTC --- (In reply to comment #5) > While trying to isolate the problem, I have observed that the problem does not > occur if -save-temps is used. > While using -save-temps does not change anything with GCC 4.7, using it does > reduce memory usage significantly with GCC 4.8. > > Did something change with regards to the way temporary files are handled? No, but using pre-processed source results in less pressure on line-tables as no macro recording is taking place. You could try -ftrack-macro-expansion=0 (which is undocumented - bah - Dodji, please fix that, invoke.texi). Unreduced preprocessed source is ok, you can also upload it somewhere accessible if it's rejected here as attachment (compress it before attaching).
[Bug tree-optimization/56756] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED CC||rguenth at gcc dot gnu.org Known to work||4.8.0 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Summary|ICE: verify_ssa failed |[4.9 Regression] ICE: |(definition in block n |verify_ssa failed |follows the use !) |(definition in block n ||follows the use !) --- Comment #3 from Richard Biener 2013-03-28 09:45:59 UTC --- Mine.
[Bug c++/56761] Error: CreateProcess: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56761 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktietz at gcc dot gnu.org Resolution||WORKSFORME --- Comment #3 from Kai Tietz 2013-03-28 09:25:25 UTC --- (In reply to comment #2) > There is no header in standard C++, so any code written in the > last 15 years should not try to use it. Nor is there such a header in mingw. Not sure where you get things from, but all in all it sounds to me like you are invoking the wrong binaries. Do you call the executable in sysroot/bin, or that from sysroot/i686-pc-mingw32/bin, or those from sysroot/mingw/bin ? Anyway please report such issues on mingw.org's ML.
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 --- Comment #7 from Jonathan Wakely 2013-03-28 09:16:52 UTC --- Read the section on name lookup changes at http://gcc.gnu.org/gcc-4.7/porting_to.html
[Bug c++/56761] Error: CreateProcess: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56761 --- Comment #2 from Jonathan Wakely 2013-03-28 09:12:15 UTC --- There is no header in standard C++, so any code written in the last 15 years should not try to use it.
[Bug c/19449] __builtin_constant_p cannot resolve to const when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19449
--- Comment #5 from Jakub Jelinek 2013-03-28
08:53:54 UTC ---
Created attachment 29742
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29742
gcc49-pr19449.patch
Untested patch. There is another case where we'd better fold
__builtin_constant_p right away, for static/extern function-local array
dimensions:
int y;
static char a[__builtin_constant_p (y) ? -1 : 1];
extern char b[__builtin_constant_p (y) ? -1 : 1];
char d[__builtin_constant_p (y) ? -1 : 1];
void
foo (int x)
{
static char e[__builtin_constant_p (x) ? -1 : 1];
extern char f[__builtin_constant_p (x) ? -1 : 1];
auto char g[__builtin_constant_p (x) ? -1 : 1];
char h[__builtin_constant_p (x) ? -1 : 1];
}
Right now this compiles fine for -O0, but for -O1 and above it errors on e and
f (twice on the latter actually). When cfun == NULL, we always fold
__builtin_constant_p right away, but when cfun is NULL, we don't consider
static/extern. Not sure how to fix this issue though, because I think the
declspecs aren't passed down to declarator parsing.
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760
--- Comment #6 from erik.thi...@thiele-hydraulik.de 2013-03-28 08:27:34 UTC ---
let me paste "v3 source code" that is also added as attachment:
namespace nam { class binbuffer {}; }
template void func (const T &a, nam::binbuffer &b);
namespace seco {
template struct holder { X *fun; };
template struct contain { T *wombat; };
}
template void func(const seco::contain &a, nam::binbuffer &b)
{ func(*a.wombat, b); }
template void func(const seco::holder &a, nam::binbuffer &b)
{ func(*a.fun, b); }
template<> void func(const int &a, nam::binbuffer &b) {}
int main()
{
nam::binbuffer b;
seco::holder foo;
func(foo, b);
seco::contain > containHolder;
func(containHolder, b); // COMMENT THIS OUT AND IT WORKS
return 0;
}
END OF CODE
when you compile this, it sais
g++ -Wall v3.cpp
/tmp/ccDElJvq.o: In function `void func
>(seco::contain > const&, nam::binbuffer&)':
v3.cpp:(.text._Z4funcIN4seco6holderIiEEEvRKNS0_7containIT_EERN3nam9binbufferE[_Z4funcIN4seco6holderIiEEEvRKNS0_7containIT_EERN3nam9binbufferE]+0x16):
undefined reference to `void func >(seco::holder const&,
nam::binbuffer&)'
collect2: error: ld returned 1 exit status
but when you comment out the line "COMMENT THIS OUT AND IT WORKS" then it
compiles.
now consider the line "func(foo, b)". here exactly the function gets called
that the linker sais is not defined. How can the linker say the function is not
defined, even though it obviously is defined?
you can make it even more clear: comment out this:
//template void func(const seco::holder &a, nam::binbuffer &b)
//{ func(*a.fun, b); }
but reenable the line "COMMENT THIS OUT AND IT WORKS"
then you get this output:
g++ -Wall v3.cpp
/tmp/cc3keqh3.o: In function `main':
v3.cpp:(.text+0x1e): undefined reference to `void func
>(seco::holder const&, nam::binbuffer&)'
/tmp/cc3keqh3.o: In function `void func
>(seco::contain > const&, nam::binbuffer&)':
v3.cpp:(.text._Z4funcIN4seco6holderIiEEEvRKNS0_7containIT_EERN3nam9binbufferE[_Z4funcIN4seco6holderIiEEEvRKNS0_7containIT_EERN3nam9binbufferE]+0x16):
undefined reference to `void func >(seco::holder const&,
nam::binbuffer&)'
collect2: error: ld returned 1 exit status
you see, it sais two times that the function is not defined. that's OK! now if
you reenable:
template void func(const seco::holder &a, nam::binbuffer &b)
{ func(*a.fun, b); }
then only the second error message keeps being there. but it misses exactly the
same function!
what's going on here? the function is there and it gets called once. why cannot
it get called twice???
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 --- Comment #5 from erik.thi...@thiele-hydraulik.de 2013-03-28 08:22:19 UTC --- Created attachment 29741 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29741 v3 source code
[Bug c++/56761] Error: CreateProcess: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56761 --- Comment #1 from Andrew Pinski 2013-03-28 07:58:29 UTC --- Where did you grab the prebuilt binraries from? gcc.gnu.org does not support prebuilt binraries really.
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 --- Comment #4 from erik.thi...@thiele-hydraulik.de 2013-03-28 07:58:00 UTC --- The example is reduced very much. Actually I have a module for "holder" and one for "contain" (separate compilation units). They do not know about each other. I have this global mechanism called "func" which everybody can make specializations for to enable his class to take part in this "func" stuff. What func does is serialize a class into the "binbuffer" binary buffer. If you create a custom class, you can let it take part in the "func" system and thus make it serializable. Everything works fine until I have a holder > or a contain >. The problem is that I cannot have a forward declaration because "contain" and "holder" don't know each other. This is like adding forward declarations in system libraries like "vector<>" for user classes which the STL developers of course cannot know. v2.cpp does not have the "nam" namespace that "v1.cpp" has. But the "nam" namespace is only for the "binbuffer" class. See that it has nothing to do with the "seco" namespace or the global namespace that "func" is inside. For that reason I do not understand why leaving out the "nam" namespace fixes the problem. I cannot find a workaround. The problem is that template implementations are inside headers. So either "holder" or "contain" is defined and implemented first. I cannot define "holder" and "contain" and then afterwards implement "holder" and "contain". This would fix my problem but then the template implementation cannot be inside the header anymore, at least I do not know how. I would need a precompiler that splits header interfaces from header implementations and first puts all interfaces and then all implementations. Is there another workaround? Sorry I do not understand your comment. Probably I miss some important point somehow. Anyway I do not find a solution...
[Bug c++/56761] New: Error: CreateProcess: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56761 Bug #: 56761 Summary: Error: CreateProcess: No such file or directory Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kharatvishal...@yahoo.co.in I have installed MinGW with GCC version 4.6.2 on 32 bit machine. But when i compile any program it gives me an error like: "CreateProcess: No such file or directory" Also mingw is missing some common header file such as iostream.h
[Bug tree-optimization/56756] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 --- Comment #2 from Marek Polacek 2013-03-28 07:38:04 UTC --- Something goes wrong in LIM.
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2013-03-28 07:14:14 UTC --- Note I think this undefined code at compile time due to specializations happen after their use though the reason why it fails are a different reason. This is expected behavior for the following reason: In the second case, we have an argument dependent lookup that happens in the global namespace so the overloaded set includes all of them at instantiation time too. So it picks the one which is specialized for seco::holder. But in the first case the overload set only includes the first two and does not know about one for seco::holder and never looks for it as argument depend lookup only happens in seco and nam as the two argument types are located in those namespaces.
[Bug tree-optimization/56756] ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-28 CC||mpolacek at gcc dot gnu.org Known to work||4.7.3 Target Milestone|--- |4.9.0 Ever Confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek 2013-03-28 07:10:23 UTC --- Confirmed. Bisecting...
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 --- Comment #2 from erik.thi...@thiele-hydraulik.de 2013-03-28 07:05:22 UTC --- You see attached two files. v1.cpp and v2.cpp g++ --version g++ (Debian 4.7.2-5) 4.7.2 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. g++ -Wall v1.cpp /tmp/ccZAyNEb.o: In function `void func >(seco::contain > const&, nam::binbuffer&)': v1.cpp:(.text._Z4funcIN4seco6holderIiEEEvRKNS0_7containIT_EERN3nam9binbufferE[_Z4funcIN4seco6holderIiEEEvRKNS0_7containIT_EERN3nam9binbufferE]+0x16): undefined reference to `void func >(seco::holder const&, nam::binbuffer&)' collect2: error: ld returned 1 exit status g++ -Wall v2.cpp --> no errors in v1.cpp you see a commented out line with a template forward declaration. if you comment that in: g++ -Wall v1.cpp --> no errors The only difference between v1 and v2 is that in v2 you do not have the "nam" namespace.
[Bug c++/56760] namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 --- Comment #1 from erik.thi...@thiele-hydraulik.de 2013-03-28 07:01:12 UTC --- Created attachment 29740 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29740 v2 source code
[Bug c++/56760] New: namespaces, templates and forwarding declarations.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760 Bug #: 56760 Summary: namespaces, templates and forwarding declarations. Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: erik.thi...@thiele-hydraulik.de Created attachment 29739 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29739 v1 source code
