[Bug target/55953] hand loop faster then builtin memset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55953 --- Comment #5 from Marc Glisse 2013-01-12 11:16:01 UTC --- See this patch: http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00336.html (the thread continues in earlier and later months)
[Bug tree-optimization/55955] New: ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955
Bug #: 55955
Summary: ICE in optab_for_tree_code, at optabs.c:402
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hi ! Using GCC 4.8.0 as of 20130112 :
$ cat optab.c
int a, b;
void f(void)
{
for(; a; a++)
{
for(b = 0; b < 2; b++)
*((unsigned short*)(0x14524875)) %= 46;
}
}
$ xgcc -O2 -ftree-vectorize -w optab.c
optab.c: In function âfâ:
optab.c:3:6: internal compiler error: in optab_for_tree_code, at optabs.c:402
void f(void)
^
0x827c81 optab_for_tree_code(tree_code, tree_node const*, optab_subtype)
../../srcdir/gcc/optabs.c:402
0xa8ba69 vectorizable_reduction(gimple_statement_d*, gimple_stmt_iterator*,
gimple_statement_d**, _slp_tree*)
../../srcdir/gcc/tree-vect-loop.c:4780
0xa806f5 vect_analyze_stmt(gimple_statement_d*, bool*, _slp_tree*)
../../srcdir/gcc/tree-vect-stmts.c:5704
0xa7f685 vect_analyze_stmt(gimple_statement_d*, bool*, _slp_tree*)
../../srcdir/gcc/tree-vect-stmts.c:5626
0x4cde84 vect_analyze_loop_operations
../../srcdir/gcc/tree-vect-loop.c:1443
0xa8a8ed vect_analyze_loop_2
../../srcdir/gcc/tree-vect-loop.c:1720
0xa8a8ed vect_analyze_loop(loop*)
../../srcdir/gcc/tree-vect-loop.c:1773
0xa9e60c vectorize_loops()
../../srcdir/gcc/tree-vectorizer.c:113
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.
[Bug testsuite/55956] New: Multiple failures on powerpc-apple-darwin9 in the acats test if the check-ada is run from the gcc directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55956 Bug #: 55956 Summary: Multiple failures on powerpc-apple-darwin9 in the acats test if the check-ada is run from the gcc directory Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ebotca...@libertysurf.fr, ia...@gcc.gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 When running check-ada on powerpc-apple-darwin9 from the build_dir/gcc, I get ~300 failures in the acats tests: === acats Summary === # of expected passes2017 # of unexpected failures303 *** FAILURES: a87b59a c330002 c34009l c354002 c354003 c35502c c35502e c35503c c35503e c35507c c35507e c35508c c35508e c37215h c380004 c390002 c39008a c39008b c39008c c393a06 c3a0014 c45613a c45613b c45613c c46014a c52103x c52104x c52104y c64201b c65003b c760010 c761004 c761006 c761007 c761011 c85018a c85018b c91004b c930001 c93004a c93004b c93004c c93004d c93004f c93005a c93005b c93005e c93005f c93005g c93005h c93007a c940013 c94001a c94001b c94001f c94002a c94008a c94008b c94008c c94008d c94020a c95022b c95040b c95040d c95065a c95065b c95065c c95065d c95065e c95065f c95085b c95085c c95085d c95085e c95085f c95085g c95095a c95095b c95095c c95095d c953001 c954013 c954014 c954016 c954018 c954019 c954023 c954024 c954025 c954a01 c954a02 c960004 c96007a c97204a c97204b c97304a c97304b c97307a c974001 c974002 c974003 c974004 c974005 c974008 c974009 c974010 c974011 c974012 c974013 c980001 c980002 c980003 c99004a c99005a c9a007a c9a009a c9a009c c9a009f c9a009g c9a009h c9a010a c9a011a c9a011b ca11001 ca11004 ca11017 ca11d01 ca11d02 cb1005a cb1010a cb1010c cb1010d cb20003 cb20006 cb20007 cb20a02 cb40005 cb4006a cb4008a cb4009a cb4013a cb40a03 cb40a04 cc3019b cc3019c cc3120b cc3602a cc70a01 cd2b11a cd2b15c cdb0a02 cdd2001 ce2102a ce2102b ce2102c ce2102h ce2102l ce2102m ce2103a ce2103b ce2110a ce2110c ce2202a ce2204a ce2204b ce2204c ce2204d ce2402a ce2404a ce2404b ce2405b ce2407a ce2407b ce2410a ce2410b ce3102a ce3102b ce3102d ce3102h ce3107a ce3114a ce3115a ce3206a ce3207a ce3302a ce3303a ce3402a ce3403a ce3403f ce3404a ce3405c ce3406b ce3406c ce3407b ce3408b ce3409a ce3409e ce3410a ce3410e ce3414a ce3601a ce3602c ce3603a ce3605c ce3701a ce3704b ce3704d ce3704e ce3704f ce3704m ce3704n ce3704o ce3705d ce3705e ce3706d ce3706f ce3707a ce3708a ce3801a ce3801b ce3804c ce3804d ce3804e ce3804g ce3804h ce3804m ce3804o ce3806a ce3806b ce3806e ce3806h ce3809a ce3809b ce3810a ce3810b ce3901a ce3905b ce3905c ce3905l ce3906b ce3906e ce3907a ce3908a cxa4001 cxa4004 cxa4005 cxa4008 cxa4009 cxa4012 cxa4015 cxa4016 cxa4019 cxa4020 cxa4026 cxa4027 cxa4030 cxa4032 cxa4034 cxa5012 cxa5a01 cxa5a02 cxa5a03 cxa5a04 cxa5a05 cxa5a06 cxa5a07 cxa5a08 cxa5a09 cxa5a10 cxa8001 cxa8003 cxaa012 cxaa013 cxaa014 cxaa015 cxaa017 cxaa018 cxac003 cxaf001 cxb3004 cxb3005 cxb3007 cxb3010 cxb3011 cxb3012 cxb4002 cxb4004 cxb4007 cxb4008 cxb5003 cxf3004 cxf3a01 cxf3a02 cxf3a03 cxf3a04 cxf3a08 cxg1003 cxg2003 cxg2011 cxg2012 cxg2013 cxg2015 cxg2016 If the tests are run from build_dir, there are only 3 failures (very old ones): === acats tests === FAIL:c52103x FAIL:c52104x FAIL:c52104y FAIL:c9a011a === acats Summary === # of expected passes2316 # of unexpected failures4 I see the same behavior in my oldest build with Ada: 4.7.0 RC1. The acats.log for the failing case can be downloaded from http://www.lps.ens.fr/~dominiq/ada/ada.tar.bz2 (bzipped tar archive for the gcc/testsuite/ada directory).
[Bug testsuite/55956] Multiple failures on powerpc-apple-darwin9 in the acats test if the check-ada is run from the gcc directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55956 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-01-12 CC|ebotcazou at libertysurf|ebotcazou at gcc dot |dot fr |gnu.org Ever Confirmed|0 |1 Severity|normal |minor --- Comment #1 from Eric Botcazou 2013-01-12 12:32:12 UTC --- Sorry, no time to deal with an obsolete platform, you're on your own here... Moreover all failures are timeout so little can be done except by you.
[Bug testsuite/55956] Multiple failures on powerpc-apple-darwin9 in the acats test if the check-ada is run from the gcc directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55956 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0 --- Comment #2 from Dominique d'Humieres 2013-01-12 12:46:11 UTC --- > Sorry, no time to deal with an obsolete platform, you're on your own here... > Moreover all failures are timeout so little can be done except by you. On my own, I'll go nowhere: I don't know Ada, I don't know how the Makefile is generated, I don't know most of what would be needed to fix the problem and I don't plan to learn most of the requisites. Indeed I am ready to do some debugging under supervision, but now that I have located the problem, I'll live perfectly happy with the bug as it triggered only because I had changed my testing routine. Now what can be done by others is to check that their platform(s) of choice is (are) immune from this problem, in particular other ppc ones. Along this line, I have forgotten to say in the original report that x86_64-apple-darwin10 does not have the problem.
[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 --- Comment #5 from Paul Thomas 2013-01-12 12:52:45 UTC --- Author: pault Date: Sat Jan 12 12:52:41 2013 New Revision: 195124 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195124 Log: 2013-01-08 Paul Thomas PR fortran/55868 * class.c (get_unique_type_string): Change $tar to STAR and replace sprintf by strcpy where there is no formatting. * decl.c (gfc_match_decl_type_spec): Change $tar to STAR. 2013-01-08 Paul Thomas PR fortran/55868 * gfortran.dg/unlimited_polymorphic_8.f90: Update scan-tree-dump-times for foo.0.x._vptr to deal with change from $tar to STAR. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_8.f90
[Bug fortran/55868] [4.8 Regression] gfortran generates for CLASS(*) __m_MOD___vtab__$tar on NO_DOLLAR_IN_LABEL systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55868 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Paul Thomas 2013-01-12 12:58:39 UTC --- Fixed on trunk. Thanks for the report. Paul
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909
--- Comment #38 from philip.copeland at oracle dot com 2013-01-12 14:10:52 UTC
---
Ugh,...
well, the good news is that I can now compile this successfully. I didn't even
need to rebuild gcc. (although I will just to follow through on Eric's
suggestion since I didn't find anything terrifically useful as a test for the
initfini-array elf header sections)
Fedora's glibc does not specifically pass --with-tls, and it is assumed that
this is automatically picked up by the configure script (it isn't but I need to
examine that as to why a bit later)
By forcing --with-tls through the configure script and reinstalling the glibc,
g++ seems to notice glibc supporting tls and generates the code necessary for
it.
The rebuilt gcc-4.7.2-8 without initfini-array support produces the same
testsuite results as previously mentioned in #c10 and #c12
+ CC=/builddir/build/BUILD/gcc-4.7.2-20121109/obj-sparc64-redhat-linux/gcc64
+ CFLAGS='-O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc'
++ echo -O2 -g -Wall -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc
++ sed 's/ -Wall / /g'
+ CXXFLAGS='-O2 -g -fexceptions -fstack-protector --param=ssp-buffer-size=4
-mcpu=ultrasparc'
+ XCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultrasparc
'
+ TCFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultrasparc
'
+ GCJFLAGS='-O2 -g -Wall -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -mcpu=ultraspar
c'
+ ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --disable-initfini-array
--build=sparc64-redhat-linux
[root@localhost ~]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-redhat-linux/4.7.2/lto-wrapper
Target: sparc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--disable-libjava-multilib --with-ppl --with-cloog --with-long-double-128
--with-cpu=ultrasparc --disable-multilib --disable-initfini-array
--build=sparc64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
[root@localhost tmp]# g++ test.c -o test
[root@localhost tmp]# ./test
we are able to write to stderr
[root@localhost tmp]#
also works
however,..
[root@localhost tmp]# readelf -S ./test | egrep "init|fini|array"
[11] .init PROGBITS 00100628 0628
[13] .fini PROGBITS 00100b60 0b60
[17] .init_array INIT_ARRAY 00200c78 0c78
.init_array somehow crept into binary despite being specifically disabled. I
dunno if that was supposed to happen but it hasn't shown any ill effect as yet
So my last thoughts are, what exactly do we loose by not supporting
initfini_array on sparc?
(From various googled sources and the gnu install.texi file):
.init_array
An array of function pointers that contributes to a single initialization
array for the executable or shared object containing the section.
.fini_array
An array of function pointers that contribute to a single termination array
for the executable or shared object containing the section."
--enable-initfini-array
Force the use of sections {.init_array} and {.fini_array}
(instead of {.init} and {.fini}) for constructors and
destructors. Option {--disable-initfini-array} has the
opposite effect. If neither option is specified, th
[Bug web/55954] Bugzilla breaks mail threading
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55954 --- Comment #3 from Jonathan Wakely 2013-01-12 14:49:43 UTC --- Without the "New" I can't keep track of new bugs at http://gcc.gnu.org/ml/gcc-bugs/2013-01/ which is how I monitor and respond to libstdc++ bugs.
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-12 CC||glisse at gcc dot gnu.org Summary|ICE in optab_for_tree_code, |[4.8 Regression] ICE in |at optabs.c:402 |optab_for_tree_code, at ||optabs.c:402 Ever Confirmed|0 |1
[Bug fortran/55789] [4.6/4.7/4.8 Regression] Needless realloc with array constructor.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | --- Comment #3 from Paul Thomas 2013-01-12 16:05:27 UTC --- I'll take this one on - see today's posting to the list. Cheers Paul
[Bug fortran/55362] [4.6/4.7/4.8 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | --- Comment #3 from Paul Thomas 2013-01-12 16:11:23 UTC --- Applying Tobias' fix to array_check seems to do the job. As to his question about the DIM arg; this and probably many more need such a check. I am surprised that it is not picked up in resolution. ifort gives [pault@localhost pr55789]$ ifort ../pr55362/p*.f90../pr55362/pr55362.f90(3): error #6423: This name has already been used as an external function name. [ERROR_MSG] write(*,*) 'message: ', size(Error_Msg),Error_Msg() ---^ ../pr55362/pr55362.f90(3): error #6361: An array-valued argument is required in this context. [SIZE] write(*,*) 'message: ', size(Error_Msg),Error_Msg() ---^ compilation aborted for ../pr55362/pr55362.f90 (code 1)
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #2 from Mikael Pettersson 2013-01-12 16:23:55 UTC --- The regression started with Jan Hubicka's "Pretty-ipa merge: Inliner heruistics reorg" patch in r147852: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00812.html http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00829.html However, that just changed inlining heuristics so most likely it exposed a latent problem. I'll start working on a reduced test case now.
[Bug fortran/55072] [4.6/4.7/4.8 Regression] Missing internal_pack leads to wrong code with derived type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55072 --- Comment #20 from janus at gcc dot gnu.org 2013-01-12 18:52:18 UTC --- Author: janus Date: Sat Jan 12 18:52:11 2013 New Revision: 195125 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195125 Log: 2013-01-12 Janus Weil PR fortran/55072 * trans-array.c (gfc_conv_array_parameter): No packing was done for full arrays of derived type. 2013-01-12 Janus Weil PR fortran/55072 * gfortran.dg/assumed_type_2.f90: Fix test case. * gfortran.dg/internal_pack_13.f90: New test. * gfortran.dg/internal_pack_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_13.f90 trunk/gcc/testsuite/gfortran.dg/internal_pack_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_type_2.f90
[Bug tree-optimization/55955] [4.8 Regression] ICE in optab_for_tree_code, at optabs.c:402
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55955
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek 2013-01-12
20:14:59 UTC ---
Yeah, started with my http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188656
Slightly reduced testcase:
int b;
void
f (int x)
{
int a;
for (a = x; a < 2; a++)
for (b = 0; b < 2; b++)
*(unsigned short *) 0x10UL %= 46;
}
Will have a look on Monday.
[Bug bootstrap/55957] New: [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 Bug #: 55957 Summary: [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org With rev. 195125: make[3]: Entering directory `/home/ig25/Gcc/trunk-bin/gcc' g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../trunk/gcc -I../../trunk/gcc/. -I../../trunk/gcc/../include -I../../trunk/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/usr/local/include -I../../trunk/gcc/../libdecnumber -I../../trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../trunk/gcc/../libbacktrace ../../trunk/gcc/tree-ssa-ccp.c -o tree-ssa-ccp.o ../../trunk/gcc/tree-ssa-ccp.c: In function 'prop_value_t evaluate_stmt(gimple)': ../../trunk/gcc/tree-ssa-ccp.c:1594:60: error: cannot convert 'built_in_class' to 'built_in_function' for argument '2' to 'bool gimple_call_builtin_p(gimple, built_in_function)' else if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
[Bug bootstrap/55957] [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from Thomas Koenig 2013-01-12 22:08:26 UTC --- This is on x86_64-unknown-linux-gnu .
[Bug c++/55958] New: vtable hidden when compiling with -fvisibility-ms-compat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55958
Bug #: 55958
Summary: vtable hidden when compiling with
-fvisibility-ms-compat
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gonsoe.com
Created attachment 29153
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29153
so1.h, so1.cxx, main.cxx, Makefile + compiler --save-temp files. Build with
'make main'
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.7/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-2ubuntu1' --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
--with-system-zlib --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 --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1)
The vtable for a class with a virtual member function is HIDDEN when source
file is compiled with -fvisibility-ms-compat. If a shared library is created
from the object file, then clients of the shared library cannot construct
objects of the class without getting an undefined symbol for the vtable.
% cat so1.h
#ifdef SO1_SOURCE
# define EXPORT __attribute ((visibility("default")))
#else
# define EXPORT
#endif
class SO1
{
public:
EXPORT virtual void foo();
};
% cat so1.cxx
#define SO1_SOURCE
#include "so1.h"
void SO1::foo() {}
% g++ -c so1.cxx -fvisibility-ms-compat
% eu-readelf -s so1.o | c++filt|grep SO1
14: 5 FUNCGLOBAL DEFAULT4 SO1::foo()
15: 12 OBJECT WEAK HIDDEN 7 vtable for SO1
16: 8 OBJECT WEAK DEFAULT9 typeinfo for SO1
18: 5 OBJECT WEAK DEFAULT 11 typeinfo name for SO1
% g++ -shared -o libso1.so so1.o
% cat main.cxx
#include "so1.h"
int main()
{
SO1 so1;
return 0;
}
% g++ main.cxx -L. -lso1
/tmp/ccLfT7tK.o: In function `SO1::SO1()':
main.cxx:(.text._ZN3SO1C2Ev[_ZN3SO1C5Ev]+0x8): undefined reference to `vtable
for SO1'
collect2: error: ld returned 1 exit status
[Bug c++/55958] vtable hidden when compiling with -fvisibility-ms-compat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55958 --- Comment #1 from Andrew Pinski 2013-01-12 23:28:08 UTC --- I think you should be marking SO1 as default visibility rather than just the member function as default visibility.
[Bug c++/55958] vtable hidden when compiling with -fvisibility-ms-compat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55958 --- Comment #2 from Soren Soe 2013-01-13 00:16:11 UTC --- Unfortunately this is a both a Linux and Windows project. I would like to reuse the windows export macros, have gcc default to -fvisibility-ms-compat so that everything except typeinfo and supposedly vtable is marked hidden, then explicitly export only what needs to be exported. My understanding is that -fvisibility-ms-compat is exactly for that purpose, but the hidden vtable is not consistent with windows.
[Bug bootstrap/55957] [4.8 Regression] Bootstrap error in prop_value_t evaluate_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55957 --- Comment #2 from Andrew Pinski 2013-01-13 04:59:57 UTC --- It works fine for me without any modifications with revision 195125.
[Bug fortran/55618] [4.6/4.7 Regression] Failures with ISO_Varying_String test suite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55618 --- Comment #8 from Paul Thomas 2013-01-13 07:51:30 UTC --- Author: pault Date: Sun Jan 13 07:51:26 2013 New Revision: 195129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195129 Log: 2013-01-13 Paul Thomas PR fortran/55618 * trans-expr.c (gfc_conv_procedure_call): Dereference scalar character function arguments to elemental procedures in scalarization loops. 2013-01-13 Paul Thomas PR fortran/55618 * gfortran.dg/elemental_scalar_args_2.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/elemental_scalar_args_2.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/fortran/trans-expr.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
