[Bug middle-end/40475] [4.5 Regression] gcc.dg/vect/vect-nest-cycle-[12].c
--- Comment #4 from irar at il dot ibm dot com 2009-06-18 07:17 --- Created an attachment (id=18017) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18017&action=view) patch to fix the tests Thanks. It's misalignment. Could you please check the attached patch? -- irar at il dot ibm dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
[Bug target/40482] New: shift a small constant to get larger one
One example is 0xff00, we can get it by mov r1, 255 lsl r1, r1, 24 Gcc generates following code: ldr r1, .L2 ... .L2 .word -16777216 -- Summary: shift a small constant to get larger one Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carrot at google dot com GCC build triplet: i686-linux GCC host triplet: i686-linux GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug target/40482] shift a small constant to get larger one
--- Comment #1 from carrot at google dot com 2009-06-18 07:34 --- Created an attachment (id=18018) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18018&action=view) test case command line option is -O2 -Os -mthumb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug regression/40483] New: gcc 4.x needs to utilize better COMDAT mechanism under Solaris
SHT_GROUP sections are used to fully support well controlled COMDAT, as detailed here: http://www.airs.com/blog/archives/52 The support for SHT_GROUP appeared in the gcc 4.x series. Since Solaris has supported SHT_GROUP since shortly after it was defined, once might assume that gcc 4.x would use SHT_GROUP under Solaris, as it does for Linux. However it's not true usually. The macro HAVE_COMDAT_GROUP is used for gcc to direct if SHT_GROUP support is available. It's found that the macro is set to 0 if configured gcc with Solaris linker and/or Solaris assembler, which means gcc has to rely on older mechanism for doing COMDAT sections known as "GNU linkonce". The assembly code as follows .section .text,"axG",@progbits,.foo,comdat is used for gcc configure to check if the specified assembler supports COMDAT group. Solaris assembler failed to assemble the code of GNU-style. For Solaris assembler for sparc, the format for COMDAT group looks like as follows: .group foo,".text%foo",#comdat .section ".text%foo" For Solaris assembler for x86, the format may look like as follows: .group __i686.get_pc_thunk.cx, .text.__i686.get_pc_thunk.cx%__i686.get_pc_thunk.cx, #comdat .section .text.__i686.get_pc_thunk.cx%__i686.get_pc_thunk.cx,"ax" __i686.get_pc_thunk.cx: Gcc 4.x assume linkers other than GNU ld don't support COMDAT group. However Solaris linkers do support it. It would be better for gcc to be able to use COMDAT group under Solaris. Besides, sparc_elf_asm_named_section in sparc/sparc.c and i386_solaris_elf_named_section in i386/i386.c have to generate COMDAT groups with satisfying format under Solaris. Any thoughts? Thanks, -- Lijuan -- Summary: gcc 4.x needs to utilize better COMDAT mechanism under Solaris Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40483
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #31 from irar at il dot ibm dot com 2009-06-18 08:03 --- Created an attachment (id=18019) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18019&action=view) patch to fix vect-42.c I think the easiest way to fix it is to change the test to have one vetorizable loop again as before http://gcc.gnu.org/viewcvs?view=rev&revision=147851. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug fortran/40451] [F03] procedure pointer assignment rejected
--- Comment #5 from janus at gcc dot gnu dot org 2009-06-18 08:09 --- Subject: Bug 40451 Author: janus Date: Thu Jun 18 08:09:40 2009 New Revision: 148652 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148652 Log: 2009-06-18 Janus Weil PR fortran/40451 * resolve.c (resolve_contained_fntype): Prevent implicit typing for procedures with explicit interface. * symbol.c (gfc_check_function_type): Ditto. 2009-06-18 Janus Weil PR fortran/40451 * gfortran.dg/proc_ptr_result_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
[Bug fortran/40451] [F03] procedure pointer assignment rejected
--- Comment #6 from janus at gcc dot gnu dot org 2009-06-18 08:13 --- Fixed with r148652. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40451
[Bug c/40469] [4.3/4.4/4.5 Regression] "Missing" uninitialized warning
--- Comment #5 from manu at gcc dot gnu dot org 2009-06-18 08:16 --- The difference is what GCC does/does not to detect/hide the warning. Here, and in 18051, the CCP pass assumes a value for the uninitialized variable, and hence, the uninit use disappears, so no warning can occur. In PR 22456, CCP does not act but there is no warning because the loop is empty and later optimizations remove it completely. See the difference now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40469
[Bug c++/40484] New: internal compiler error
OS: FreeBSD 7.2 Compiler: g++ (gcc version 4.2.1 20070719 [FreeBSD]) Traceback: /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../confi g -I/usr/local/include/ -I/usr/local/include/python2.5 -I/usr/local/include -I /usr/local/include/ImageMagick -g -O2 -DBOOST_PYTHON_DYNAMIC_LIB -MT libpymagick _la-_Exception.lo -MD -MP -MF .deps/libpymagick_la-_Exception.Tpo -c -o libpymag ick_la-_Exception.lo `test -f '_Exception.cpp' || echo './'`_Exception.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../config -I/usr/local/include/ -I/ usr/local/include/python2.5 -I/usr/local/include -I/usr/local/include/ImageMagic k -g -O2 -DBOOST_PYTHON_DYNAMIC_LIB -MT libpymagick_la-_Exception.lo -MD -MP -MF .deps/libpymagick_la-_Exception.Tpo -c _Exception.cpp -fPIC -DPIC -o .libs/lib pymagick_la-_Exception.o /usr/local/include/boost/type_traits/detail/cv_traits_impl.hpp: In instantiation of 'const bool boost::detail::cv_traits_imp<::Magick_Exception_Wrapper *>::is_const': /usr/local/include/boost/type_traits/is_const.hpp:57: instantiated from 'boost ::is_const<::Magick_Exception_Wrapper>' /usr/local/include/boost/python/detail/cv_category.hpp:31: instantiated from ' boost::python::detail::cv_category<::Magick_Exception_Wrapper>' /usr/local/include/boost/python/detail/unwind_type.hpp:58: instantiated from ' typename Generator::result_type boost::python::detail::unwind_ptr_type(U*, Gener ator*) [with Generator = boost::python::converter::detail::unwind_type_id_helper , U = ::Magick_Exception_Wrapper]' /usr/local/include/boost/python/detail/unwind_type.hpp:127: instantiated from 'static typename Generator::result_type boost::python::detail::unwind_helper2<2> ::execute(U& (*)(), Generator*) [with Generator = boost::python::converter::deta il::unwind_type_id_helper, U = ::Magick_Exception_Wrapper]' /usr/local/include/boost/python/detail/unwind_type.hpp:165: instantiated from 'typename Generator::result_type boost::python::detail::unwind_type(boost::type< U>*, Generator*) [with Generator = boost::python::converter::detail::unwind_type _id_helper, U = ::Magick_Exception_Wrapper&]' /usr/local/include/boost/python/converter/pytype_function.hpp:45: instantiated from 'boost::python::type_info boost::python::converter::detail::unwind_type_id _(boost::type*, mpl_::false_*) [with T = ::Magick_Exception_Wra pper&]' /usr/local/include/boost/python/converter/pytype_function.hpp:68: instantiated from 'static const PyTypeObject* boost::python::converter::expected_pytype_for_ arg::get_pytype() [with T = ::Magick_Exception_Wrapper&]' /usr/local/include/boost/python/detail/signature.hpp:98: instantiated from 'st atic const boost::python::detail::signature_element* boost::python::detail::sign ature_arity<1u>::impl::elements() [with Sig = boost::mpl::vector2::Magick_Exception_Wrapper&>]' /usr/local/include/boost/python/detail/caller.hpp:232: instantiated from 'stat ic boost::python::detail::py_func_sig_info boost::python::detail::caller_arity<1 u>::impl::signature() [with F = const char* (::Magick _Exception_Wrapper::*)()const, Policies = boost::python::default_call_policies, Sig = boost::mpl::vector2::Magick_Exception_Wrapper&>]' /usr/local/include/boost/python/object/py_function.hpp:48: instantiated from ' boost::python::detail::py_func_sig_info boost::python::objects::caller_py_functi on_impl::signature() const [with Caller = boost::python::detail::caller< const char* (::Magick_Exception_Wrapper::*)()const, boost::python::defa ult_call_policies, boost::mpl::vector2::Magick_Exception_ Wrapper&> >]' _Exception.cpp:45: instantiated from here /usr/local/include/boost/type_traits/detail/cv_traits_impl.hpp:37: internal compiler error: in make_rtl_for_nonlocal_decl, at cc1plus/../../../../contrib/gcc/cp/decl.c:4971 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /usr/home/maxp/python/PythonMagick-0.9.1/pythonmagick_src. *** Error code 1 -- Summary: internal compiler error Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: maxp at sterch dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40484
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #32 from dominiq at lps dot ens dot fr 2009-06-18 08:46 ---
With the patch in comment #31 I get:
Running target unix
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ...
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 2
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
=== gcc Summary for unix ===
# of expected passes3
# of unexpected failures2
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ...
ERROR: gcc.dg/vect/vect-42.c: error executing dg-final: syntax error in target
selector "target !vect_hw_misalign"
=== gcc Summary for unix/-m64 ===
# of expected passes3
# of unresolved testcases 1
The syntax error is fixed by replacing {!vect_hw_misalign} with { !
vect_hw_misalign }. For the 32 bit mode, the failures are consistent with:
[karma] f90/bug% gfc -O3 -fdump-tree-vect-details
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect-42.c
[karma] f90/bug% grep unaligned vect-42.c.105t.vect
[karma] f90/bug% grep peeling vect-42.c.105t.vect
[karma] f90/bug% grep versioning vect-42.c.105t.vect
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect-42.c:37: note: versioning
for alias required: can't determine dependence between b[i_17] and *D.2095_6
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect-42.c:37: note: versioning
for alias required: can't determine dependence between c[i_17] and *D.2095_6
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect-42.c:37: note: Alignment
of access forced using versioning.
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect-42.c:37: note: created 2
versioning for alias checks.
i.e., no "unaligned" nor "peeling" found.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug fortran/40461] Interface mismatch in dummy procedure
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-18 08:49 --- I close this as INVALID. If you have suggestions how to improve the diagnostics or if you disagree, feel free to reopen the bug. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40461
[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association
--- Comment #3 from burnus at gcc dot gnu dot org 2009-06-18 09:00 --- Patch: http://gcc.gnu.org/ml/fortran/2009-06/msg00188.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
[Bug fortran/40461] Interface mismatch in dummy procedure
--- Comment #4 from dominiq at lps dot ens dot fr 2009-06-18 09:03 --- > I close this as INVALID. Late note: ifort gives an error also pr40461.f90(19): error #7061: The characteristics of dummy argument 1 of the associated actual procedure differ from the characteristics of dummy argument 1 of the dummy procedure. (12.2) [LOGISTIC4] CALL halprn(Logistic4) ^ compilation aborted for pr40461.f90 (code 1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40461
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #33 from irar at il dot ibm dot com 2009-06-18 09:14 --- Created an attachment (id=18020) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18020&action=view) fix vect-42.c OK, now I understand why we need two loops here (we need to pass the arrays as parameters to avoid versioning for alias). So, I split the checks for vect_no_align and the others. Hope, this time it works. Thanks. -- irar at il dot ibm dot com changed: What|Removed |Added Attachment #18019|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug target/40482] shift a small constant to get larger one
--- Comment #2 from ramana at gcc dot gnu dot org 2009-06-18 09:18 --- I can confirm this for Thumb1 which is what I presume you are interested in. Also, please note that -O2 -Os is the same as -Os. We have a splitter that should ideally take care of this case. Digging. -- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-18 09:18:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug c/40485] New: definitions of __builtin_abs() and abs() function in one module
Hello.
gcc always replaces the name of the defined "__builtin_abs()" with "abs()". And
it might cause the error if we also wants to define "abs()" function:
$ cat t.c
int abs(int a) {return 0;}
int __builtin_abs(int a) {return 0;}
int main(void)
{
return (abs(-3) + __builtin_abs(-3));
}
$ gcc t.c -c
/tmp/ccdecizd.s: Assembler messages:
/tmp/ccdecizd.s:14: Error: symbol `abs' is already defined
In the case of "static" functions it's OK:
$ cat t.c
static int abs(int a) {return 0;}
static int __builtin_abs(int a) {return 0;}
int main(void)
{
return (abs(-3) + __builtin_abs(-3));
}
$ gcc t.c -c ; echo $?
0
In this case we use unchanged names for the functions' call:
$ gcc t.c -S && grep call t.s
callabs
call__builtin_abs
This issue doesn't occur only on abs but also with the others builtins.
$ ~/programs/gcc-4.4.0/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/home/glushkov/programs/gcc-4.4.0
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 (GCC)
$ uname -a
Linux expert 2.6.23-gentoo-r9-c2-uni1 #1 SMP Thu Jun 5 13:00:21 MSD 2008 i686
Intel(R) Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux
--
Summary: definitions of __builtin_abs() and abs() function in one
module
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ivan dot glushkov at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|regression |target GCC target triplet||i386-solaris Summary|gcc 4.x needs to utilize|gcc 4.x needs to utilize |better COMDAT mechanism |better COMDAT mechanism |under Solaris |under Solaris http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40483
[Bug c++/40484] internal compiler error
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-18 09:34 --- GCC 4.2.x is no longer maintained, please try at least GCC 4.3.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40484
[Bug c/40485] definitions of __builtin_abs() and abs() function in one module not diagnosed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-18 09:35 --- This is really invalid code, but we should diagnose it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2009-06-18 09:35:53 date|| Summary|definitions of |definitions of |__builtin_abs() and abs() |__builtin_abs() and abs() |function in one module |function in one module not ||diagnosed Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #6 from pault at gcc dot gnu dot org 2009-06-18 09:44 --- (In reply to comment #5) > Juergen: Thanks for the report, but it is not a regression - it might not > crash > with 4.3 (or your 4.4) but I think that's just by chance. > > Paul, I think also this bug touches code for which you have the expertise. > > The problem is the automatic deallocation of an allocatable component. The DT > with this component is returned by a function but treated as variable and not > as function. The crucial part is that the return value is a pointer! If I Ys there is a bug there somewhere. I shall have to think this through. I am not sure that your testcase should be allowed at all! I am not sure that I understand what it means. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug c/40485] definitions of __builtin_abs() and abs() function in one module not diagnosed
--- Comment #2 from ivan dot glushkov at gmail dot com 2009-06-18 09:48 --- Why invalid? And why non-static is not invalid? Can you please give me reference to documentation where it's described? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug target/40482] shift a small constant to get larger one
--- Comment #3 from ramana at gcc dot gnu dot org 2009-06-18 09:50 --- Testing a patch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40482
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #26 from matz at gcc dot gnu dot org 2009-06-18 11:26 --- Hmm, yeah, I should probably clean up my hack and formally submit it. But I had hoped to get some advise from the frontend guys, because I was surprised that the patch actually worked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug c/40454] GCC 4.4.0 vs 3.4.0 - PNGCrush is about 20% slower when compiled with GCC 4.4.0
--- Comment #1 from ami_stuff at o2 dot pl 2009-06-18 11:27 --- Anyone can try to reproduce this bug on his system? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454
[Bug c++/40486] New: [c++0x] rvalue-references no longer bind to lvalues
I'm surprised this hasn't been implemented already. AFAIK, it was accepted and is in the current draft. http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00436.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2844.html The patch still applies to the compiler itself. However, the patch doesn't handle issues addressed in update from N2831. Also, library part doesn't apply, although I believe it would be trivial to update. -- Summary: [c++0x] rvalue-references no longer bind to lvalues Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dragan at plusplus dot co dot yu GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- Comment #1 from paolo dot carlini at oracle dot com 2009-06-18 11:57 --- Let's CC Jason... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
--- Comment #4 from jwakely dot gcc at gmail dot com 2009-06-18 12:43 --- (In reply to comment #2) > It seems strange to me that clear() allows memory_order_consume but not > acquire. I'll ask on the lib reflector if that's an oversight, I asked and everyone agreed it should disallow consume so Lawrence Crowl will address it in a forthcoming paper. (In reply to comment #3) > me, so yes proceed please. I'm still not sure that this kind of debug mode > only > error handling is correct but it seems like an approach that is vaguely > familiar from other parts of the library. So at least usage is consistent, > even > if the original implementation was plain wrong The approach seems fine to me, but then I'm a frequent user of _GLIBCXX_DEBUG anyway. > There are many problems with memory ordering in the atomics2 implementation. > It > is known to be incorrect and incomplete, as the saying goes. The goal was to > start experimenting with compliler builtins assuming x86_64 hardware and see > how far we got, what kind of compiler intrinsics we needed first, how we test > this stuff, etc etc. The current code is more than good enough to let me start experimenting and feeling my way around so please take my comments as feedback not complaints :-) I'll prepare a patch to reverse the sense of the debug assertions, but won't change anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug libstdc++/40297] [C++0x] debug mode vs atomics
-- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jwakely dot gcc at gmail dot |dot org |com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-18 12:48:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40297
[Bug target/40487] New: Extra zero extensions produced for ARM.
A colleague at ARM found this a couple of days back.
With trunk as of a few days back configured for arm-none-eabi for cortex-a8
typedef unsigned short ushort;
typedef unsigned char uchar;
ushort foo(uchar data, uchar data1, uchar data2)
{
uchar x = (uchar)(data);
x ^= (x + 5);
x ^= (x << 2);
x ^= (x << 1);
return x;
}
foo:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add r3, r0, #5
eor r0, r3, r0
uxtbr0, r0 //redundant
eor r0, r0, r0, lsl #2
uxtbr0, r0 // redundant
eor r0, r0, r0, lsl #1
uxtbr0, r0
bx lr
--
Summary: Extra zero extensions produced for ARM.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #1 from ramana at gcc dot gnu dot org 2009-06-18 12:58 --- I'm not sure about the best way of fixing this without looking at bigger trees at expand time or for combine to be able to do something smart about this one. Essentially you fold the previous zero extension with the current operation because the current operation doesn't care about the higher order bits and there is a zero extension afterwards that puts it into the right shape. x = zextb (y) z = x ^ (x << #n) w = zextb (z) into x = y ^ (y << #n) w = zextb (x) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #34 from dominiq at lps dot ens dot fr 2009-06-18 12:59 --- With the patch in comment #33, I get on powerpc-apple-darwin9: Running target unix Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ... === gcc Summary for unix === # of expected passes5 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ... === gcc Summary for unix/-m64 === # of expected passes4 # of expected failures 2 and on i686-apple-darwin9: Schedule of variations: unix unix/-m64 Running target unix Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ... === gcc Summary for unix === # of expected passes3 # of expected failures 2 Running target unix/-m64 Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/vect/vect.exp ... === gcc Summary for unix/-m64 === # of expected passes3 # of expected failures 2 So the patch fixes the last problem (at least for these platforms). Thanks for your patience! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- Comment #2 from jwakely dot gcc at gmail dot com 2009-06-18 13:11 --- I've already done the library parts on trunk, see http://gcc.gnu.org/ml/libstdc++/2009-05/msg00114.html I'll review Doug's patch to see if I missed anything. N.B. the changes to std::move and std::forward were *not* accepted into the WP yet, I think there's ongoing work in that area. Because of that, I'm not sure what would happen if the front end changes were applied (I think the current definitions of std::move and std::forward would break large parts of the library!) -- jwakely dot gcc at gmail dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-18 13:13 --- Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept lvalues according to the current draft. That needs fixing too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug testsuite/40488] New: [4.5 Regression] Revision 148642 caused extra failures
Revision 148642: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00625.html caused: FAIL: gfortran.dg/bind_c_usage_13.f03 -O scan-tree-dump original "mult .&.u..1..lb: 1 sz: 1., &.x..1..lb: 1 sz: 1., 1, 1.;" FAIL: gfortran.dg/bind_c_usage_13.f03 -O scan-tree-dump original "mult_array .&.abc..1..lb: 1 sz: 1., &.ab..1..lb: 1 sz: 1., 3, 2.;" FAIL: gfortran.dg/bind_c_usage_13.f03 -O scan-tree-dump original "mult_val ..x., .x., 1, 1.;" FAIL: gfortran.dg/bind_c_usage_13.f03 -O scan-tree-dump original "sub .&.u..1..lb: 1 sz: 1., 1.;" FAIL: gfortran.dg/bind_c_usage_13.f03 -O scan-tree-dump original "sub_array .&.abc..1..lb: 1 sz: 1., 3.;" FAIL: gfortran.dg/bind_c_usage_13.f03 -O scan-tree-dump original "sub_val ..x., 1.;" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.0.sub3noiso .0, 0B, 0B, 0B, b, a, 0, 0, 1, 1\);" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.0.sub3noiso .1, z, y, x, 0B, 0B, 1, 1, 0, 0\);" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.1.sub4iso .0, 0B, 0B, 0B, b, a, 0, 0, 1, 1\);" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.1.sub4iso .1, z, y, x, 0B, 0B, 1, 1, 0, 0\);" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.2.sub5iso .0, 0B, 0B, 0B, b, a, 0, 0, 1, 1\);" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.2.sub5iso .1, z, y, x, 0B, 0B, 1, 1, 0, 0\);" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.3.sub6noiso .0, 0B, 0B, 0B, b, a, 0, 0, 1, 1\);" FAIL: gfortran.dg/bind_c_usage_14.f03 -O scan-tree-dump original "master.3.sub6noiso .1, z, y, x, 0B, 0B, 1, 1, 0, 0\);" FAIL: gfortran.dg/c_f_pointer_tests_3.f90 -O scan-tree-dump-times original "c_f" 1 FAIL: gfortran.dg/c_f_pointer_tests_3.f90 -O scan-tree-dump-times original "c_f_pointer" 1 FAIL: gfortran.dg/c_f_pointer_tests_3.f90 -O scan-tree-dump-times original "c_f_pointer_i4" 1 FAIL: gfortran.dg/missing_optional_dummy_4.f90 -O scan-tree-dump original " tm_doit \(0B, 0\);" FAIL: gfortran.dg/missing_optional_dummy_5.f90 -O scan-tree-dump original " tm_doit \(&parm.(6|7), 0B, 0\);" -- Summary: [4.5 Regression] Revision 148642 caused extra failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40488
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #7 from juergen dot reuter at desy dot de 2009-06-18 13:33 --- (In reply to comment #6) > (In reply to comment #5) The crucial part is that the return value is a pointer! If I > > Ys there is a bug there somewhere. I shall have to think this through. > I am not sure that your testcase should be allowed at all! I am not sure that > I understand what it means. > > Paul Dear Paul, if you need any help please let me know. It might also be possible that we wrote some code contradicting conventions, which would be valuable to know. I'm still convinced that this is a problem of the compiler, since it works with the NAG and Intel compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug c/40485] definitions of __builtin_abs() and abs() function in one module not diagnosed
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-18 13:48 --- The __builtin_ namespace is reserved by GCC. There may be documentation missing for this fact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug target/40487] Extra zero extensions produced for ARM.
--- Comment #2 from steven at gcc dot gnu dot org 2009-06-18 14:00 --- Why does the zero-bits machinery in combine not make these redundant extensions go away? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40487
[Bug testsuite/40359] [4.5 Regression] Revision 148211 caused a lot of failures in the vect test suite.
--- Comment #35 from eres at il dot ibm dot com 2009-06-18 14:06 --- Created an attachment (id=18021) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18021&action=view) Final version of the patch I'll submit the following patch -- it contains Ira's latest fix and two syntax errors fixes. Thanks again for helping! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- Comment #4 from dragan at plusplus dot co dot yu 2009-06-18 14:19 --- (In reply to comment #3) > Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept > lvalues according to the current draft. That needs fixing too. > If you are referring to: template pair make_pair(T1&& x, T2&& y); I'm not into concepts yet (the reason being obvious :-), but I think T1,T2 can be lvalue-references. Unfortunately, in this case, under reference collapsing rules, this _will_ accept lvalues and perfectly forward them to the pair constructor. Am I off the track here? As for deducing pair template parameters as described in WP, I can only see symptoms of "coding under influence" :-D I say "unfortunately" above, because I don't like the syntax (namely &&) used to express a function that can take both lvalues and rvalues. I have objected on comp.std.c++, but got no real support. Also, about move and forward. IMHO, those presented in the patch seem fine. Did I understand correctly that the only thing you are waiting is acceptance into WP? I guess the functionality will remain the same. It might be they have issues with concepts. I'm only guessing, so I apologize if you have some _solid_ information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug c++/40484] internal compiler error
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-06-18 14:29 --- Also provide the preprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40484
[Bug c/40469] [4.3/4.4/4.5 Regression] "Missing" uninitialized warning
--- Comment #6 from hp at gcc dot gnu dot org 2009-06-18 14:30 --- (In reply to comment #5) > See the difference now? Thanks, that helped. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40469
[Bug c/39855] [4.3 Regression] Shift optimization discards operands' side effects
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-06-18 14:44 --- Testing backport. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jakub at gcc dot gnu dot org|rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39855
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-18 14:45 --- > I am not sure that your testcase should be allowed at all! I am not sure that > I understand what it means. I think it is valid and not different from: integer, pointer :: ptr allocate(ptr) ptr = 5 call f(ptr) where you don't pass the pointer "ptr" to "f" but the target of pointer "f". My example is invalid, however, as I never set the return value. Add allocate(func) if you want. That should make it valid as one now has a pointer target. But it shouldn't matter regarding the bug. (The not-needed "target" attribute can also be removed.) Regarding the big program: function f(tgt) integer,target :: tgt f => tgt end function f I am not sure that using "tgt" as return value is valid; I think as soon as one leaves "f", the "tgt" dummy ceases to exist, which would make it invalid. But I might be wrong and it is valid. In practice, it should work if the actual argument is either in static memory or one uses the pointer while the target is still on the stack (or on the heap). (If one wants to check the validity, one needs to read all about pointers, targets and argument association - and maybe scope - in the standard.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug target/39240] [4.3 Regression] Invalid sibcall optimization with promoted return types and differing signedness
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-06-18 14:45 --- Testing backport. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jakub at gcc dot gnu dot org|rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39240
[Bug c/40476] SEG fault on redefinition of struct error
--- Comment #2 from tor_rustad at hotmail dot com 2009-06-18 14:47 ---
(In reply to comment #1)
> Works for me.
>
> gcc-4.2 --version
> gcc-4.2 (GCC) 4.2.4 (Debian 4.2.4-6)
The seg fault happened with
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
unintentionally I left out two semicolons in the test case, the corrected test
case is:
$ cat test.c
struct R
{
char c;
};
struct R
{
struct R r;
};
int main(void)
{
struct R r;
return 0;
}
$ gcc test.c
test.c:7: error: redefinition of struct R
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
$ gcc -std=c89 test.c
test.c:7: error: redefinition of struct R
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
$ gcc -std=c99 test.c
test.c:7: error: redefinition of struct R
gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.
--
tor_rustad at hotmail dot com changed:
What|Removed |Added
CC||tor_rustad at hotmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40476
[Bug target/39013] [4.3 Regression] Missing @PLT when -fpie is used
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-06-18 14:50 --- Testing a backport. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jakub at gcc dot gnu dot org|rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39013
[Bug c/40485] definitions of __builtin_abs() and abs() function in one module not diagnosed
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-06-18 14:51 --- All of __* namespace s reserved for the implementor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug tree-optimization/38369] [4.3 regression] ICE (SIGSEGV in number_of_iterations_exit)
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-06-18 15:00 --- Re-confirmed on the branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-12-04 13:09:34 |2009-06-18 15:00:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38369
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-18 15:17 --- (In reply to comment #7) > I'm still convinced that this is a problem of the compiler, since it works > with the > NAG and Intel compilers. Well, compilers can have all bugs - and not all invalid programs can be diagnosed as such by a compiler. In any case, I believe gfortran has a bug (cf. comment 5 and comment 8). (In reply to comment #8) > Regarding the big program: [...] I think the big program is valid (at least with this regard) as the following applies. "If the dummy argument has the TARGET attribute, does not have the VALUE attribute, and is either a scalar or an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript then (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure and (2) When execution of the procedure completes, any pointers that do not become undefined (16.4.2.1.3) and are associated with the dummy argument remain associated with the actual argument." [F2003, 12.4.1.2 Actual arguments associated with dummy data objects] And in "16.4.2.1.3 Events that cause the association status of pointers to become undefined". Relevant would be for instance: "(4) Execution of a RETURN or END statement causes the pointers target to become undefined (item (3) of 16.5.6)," which is never the case for the PROGRAM; additionally, the SAVE preserves it even longer [(3) in 16.5.6]: "Variables become undefined as follows: [...] (3) When execution of an instance of a subprogram completes, (a) its unsaved local variables become undefined," -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-06-18 15:38 --- Danny, any news here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- Comment #5 from jwakely dot gcc at gmail dot com 2009-06-18 15:39 --- (In reply to comment #4) > (In reply to comment #3) > > Also, n2844 and Doug's patch don't update std::make_pair, so it won't accept > > lvalues according to the current draft. That needs fixing too. > > > > If you are referring to: > > template > pair make_pair(T1&& x, T2&& y); > > I'm not into concepts yet (the reason being obvious :-), but I think > T1,T2 can be lvalue-references. Unfortunately, in this case, under > reference collapsing rules, this _will_ accept lvalues and perfectly forward > them to the pair constructor. Ah, OK, I hadn't understood that correctly, thanks for the explanation. > Am I off the track here? As for deducing pair template parameters as described > in WP, I can only see symptoms of "coding under influence" :-D I'm not sure, so I'll take your word for it :-) > I say "unfortunately" above, because I don't like the syntax (namely &&) > used to express a function that can take both lvalues and rvalues. > I have objected on comp.std.c++, but got no real support. > Also, about move and forward. IMHO, those presented in the patch > seem fine. Did I understand correctly that the only thing you > are waiting is acceptance into WP? I guess the functionality will > remain the same. It might be they have issues with concepts. > I'm only guessing, so I apologize if you have some _solid_ information. Yes, I was just pointing out that the WP currently doesn't have the changes to std::forward and std::move - I don't know why, or what the final versions might look like. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug tree-optimization/40321] [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501
--- Comment #15 from dberlin at gcc dot gnu dot org 2009-06-18 15:48 --- Subject: Re: [4.4/4.5 Regression] internal compiler error: in compute_antic, at tree-ssa-pre.c:2501 No, still trying to figure it out. It's quite tricky. On Thu, Jun 18, 2009 at 11:38 AM, rguenth at gcc dot gnu dot org wrote: > > > --- Comment #14 from rguenth at gcc dot gnu dot org 2009-06-18 15:38 > --- > Danny, any news here? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- Comment #6 from jason at redhat dot com 2009-06-18 16:26 --- Subject: Re: [c++0x] rvalue-references no longer bind to lvalues On 06/18/2009 11:39 AM, jwakely dot gcc at gmail dot com wrote: > Yes, I was just pointing out that the WP currently doesn't have the changes to > std::forward and std::move - I don't know why, or what the final versions > might > look like. Because there were strong objections to those changes at the meeting. People have been working on a different solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers
--- Comment #5 from manu at gcc dot gnu dot org 2009-06-18 16:28 --- (In reply to comment #4) > It is an uninitialized use in an exception handler. Is it an explicit exception handler? Or a compiler-generated? In any case, it looks like the code is actually executed, so it may well be a bug in the code. -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||24639 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers
--- Comment #6 from manu at gcc dot gnu dot org 2009-06-18 16:30 --- This is marked as a 4.4 regression. Does it happen in trunk? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
[Bug c/40474] gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2)
--- Comment #7 from manu at gcc dot gnu dot org 2009-06-18 16:43 --- The warning was removed on purpose per user request, so this is WONTFIX. We are sorry about the inconvenience this causes to you. We humbly suggest you consider using a more modern editor, for example emacs, which will introduce a newline at the end of the file. Otherwise, your colleagues could perhaps update to the same version of GCC you are using. Developing with different versions of GCC is likely to cause some discrepancies because of fixed/new bugs. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40474
[Bug c++/40486] [c++0x] rvalue-references no longer bind to lvalues
--- Comment #7 from dragan at plusplus dot co dot yu 2009-06-18 17:09 --- (In reply to comment #6) > Because there were strong objections to those changes at the meeting. > People have been working on a different solution. I know this is a bad place to continue the discussion on this topic, so I would like to know if there are any documents or articles, or other ways to get involved into the matter? Are people objecting the whole lvalue/rvalue-reference solution, or only move/forward part and why? The only relevant thread on comp.std.c++ I could find is "Catch by rvalue reference" that continues to "std::move and lvalues (was: re: catch by rvalue reference)" ... but nothing there... Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
[Bug middle-end/40156] [4.4 Regression] Possible bogus warning in libstdc++ headers
--- Comment #7 from paolo dot carlini at oracle dot com 2009-06-18 17:19 --- Today I can't reproduce it neither with mainline nor with 4_4-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40156
[Bug c/40474] gcc 4.3 no longer warns about missing newlines at end of files (regression from 4.2)
--- Comment #8 from rlerallut at free dot fr 2009-06-18 18:04 --- (In reply to comment #7) > The warning was removed on purpose per user request, so this is WONTFIX. Keeping an once of compatibility (or adding an option) between two minor versions would have been appreciated. Or a pragma, whatever. Not all of us have the luxury of a homogeneous development environment. > We are sorry about the inconvenience this causes to you. We humbly suggest you > consider using a more modern editor, for example emacs, which will introduce a > newline at the end of the file. So does vim [flamebait right back at you]. However many of my colleagues use visual c++ which does not have this feature (or not by default). > Otherwise, your colleagues could perhaps update > to the same version of GCC you are using. Developing with different versions > of > GCC is likely to cause some discrepancies because of fixed/new bugs. Yes. Not to mention the various behavior in floating point optimizations. Most of our Linux-using developers use gcc 4.2 on Ubuntu's latest "long term support" release. But part of my job is to evaluate the compilers we have available (or will have in the future). I therefore routinely use gcc from 4.1 to 4.4 as well as intel's icc and visual c++. It's already hard enough being one of the few linux people in a windows shop, you're not making my task easier. Well, I guess you can't please everyone all the time. Wontfix it is. I'll patch my local copy. Regards, Romain -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40474
[Bug middle-end/40475] [4.5 Regression] gcc.dg/vect/vect-nest-cycle-[12].c
--- Comment #5 from hjl dot tools at gmail dot com 2009-06-18 18:39 --- (In reply to comment #4) > Created an attachment (id=18017) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18017&action=view) [edit] > patch to fix the tests > > Thanks. It's misalignment. > Could you please check the attached patch? > It works. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
[Bug target/40489] New: gcc.dg/builtin-unreachable-3.c doesn't work on ia64
I got
Executing on host: /export/build/gnu/gcc/build-ia64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/gcc/
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/builtin-unreachable-3.c
-O2 -S -o builtin-unreachable-3.s(timeout = 300)
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/builtin-unreachable-3.c:
In function 'f':^M
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/builtin-unreachable-3.c:9:1:
internal compiler error: Segmentation fault^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <http://gcc.gnu.org/bugs.html> for instructions.^M
Starting program: /export/build/gnu/gcc/build-ia64-linux/stage1-gcc/cc1
-fpreprocessed /tmp/x.i -quiet -dumpbase x.i -auxbase x -O2 -version -o x.s
GNU C (GCC) version 4.5.0 20090618 (experimental) [trunk revision 148658]
(ia64-unknown-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-9), GMP version
4.2.2, MPFR version 2.3.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.5.0 20090618 (experimental) [trunk revision 148658]
(ia64-unknown-linux-gnu)
compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-9), GMP version
4.2.2, MPFR version 2.3.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8913ea3e9927da81125036b21150e23a
Program received signal SIGSEGV, Segmentation fault.
0x40ff2041 in ia64_reorg ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/config/ia64/ia64.c:9243
9243 while (GET_CODE (insn) == INSN && get_attr_empty (insn) ==
EMPTY_YES)
(gdb) list
9238
9239 insn = get_last_insn ();
9240 if (! INSN_P (insn))
9241insn = prev_active_insn (insn);
9242 /* Skip over insns that expand to nothing. */
9243 while (GET_CODE (insn) == INSN && get_attr_empty (insn) ==
EMPTY_YES)
9244{
9245 if (GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE
9246 && XINT (PATTERN (insn), 1) ==
UNSPECV_INSN_GROUP_BARRIER)
9247saw_stop = 1;
(gdb) r
Breakpoint 3, ia64_reorg ()
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/config/ia64/ia64.c:9240
9240 if (! INSN_P (insn))
(gdb) call debug_rtx (insn)
(note 15 5 0 NOTE_INSN_DELETED)
(gdb) next
9241insn = prev_active_insn (insn);
(gdb)
9243 while (GET_CODE (insn) == INSN && get_attr_empty (insn) ==
EMPTY_YES)
(gdb) p insn
$4 = (rtx) 0x0
(gdb)
--
Summary: gcc.dg/builtin-unreachable-3.c doesn't work on ia64
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: ia64-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40489
[Bug bootstrap/40061] [4.3 Regression] Bootstrap failure in dwarf2out.c, function add_subscript_info: 'dimension_number' undefined
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-18 20:06 --- Subject: Bug 40061 Author: burnus Date: Thu Jun 18 20:06:04 2009 New Revision: 148668 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148668 Log: 2009-06-18 Tobias Burnus Mikael Pettersson PR debug/40061 * dwarf2out.c (add_subscript_info): Fix build for MIPS_DEBUGGING_INFO. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40061
[Bug bootstrap/40061] [4.3 Regression] Bootstrap failure in dwarf2out.c, function add_subscript_info: 'dimension_number' undefined
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-18 20:06 --- Hopefully now really FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40061
[Bug fortran/40450] [F03] procedure pointer as actual argument
--- Comment #1 from janus at gcc dot gnu dot org 2009-06-18 20:27 ---
Here is a preliminary patch which fixes the test case:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 148651)
+++ gcc/fortran/trans-expr.c(working copy)
@@ -2646,7 +2646,9 @@ gfc_conv_procedure_call (gfc_se * se, gf
if (fsym && e->expr_type != EXPR_NULL
&& ((fsym->attr.pointer
&& fsym->attr.flavor != FL_PROCEDURE)
- || fsym->attr.proc_pointer))
+ || (fsym->attr.proc_pointer
+ && !(e->expr_type == EXPR_VARIABLE
+ && e->symtree->n.sym->attr.dummy
{
/* Scalar pointer dummy args require an extra level of
indirection. The null pointer already contains
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-06-18 20:27:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40450
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #10 from pault at gcc dot gnu dot org 2009-06-18 20:51 --- (In reply to comment #8) > > I am not sure that your testcase should be allowed at all! I am not sure > > that > > I understand what it means. > > I think it is valid and not different from: Yes, I understood after a bit of dyslexia about it :-( Since the function result is a pointer, it is an ultimate component and, I think, the deallocation of the allocatable components should not be attempted. If you agree with me, I'll make it so. Otherwise, it'll need a temporary. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug target/40489] gcc.dg/builtin-unreachable-3.c doesn't work on ia64
--- Comment #1 from hjl dot tools at gmail dot com 2009-06-18 20:55 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01520.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||sje at cup dot hp dot com URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||06/msg01520.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40489
[Bug c/40485] definitions of __builtin_abs() and abs() function in one module not diagnosed
--- Comment #5 from joseph at codesourcery dot com 2009-06-18 21:08 --- Subject: Re: definitions of __builtin_abs() and abs() function in one module not diagnosed What happened to the patch for PR 32455 to disallow __builtin_* declarations? That PR indicates it was approved for 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40485
[Bug target/40470] unable to find a register to spill in class �SSE_FIRST_REG�
--- Comment #7 from hjl at gcc dot gnu dot org 2009-06-18 21:12 --- Subject: Bug 40470 Author: hjl Date: Thu Jun 18 21:12:12 2009 New Revision: 148673 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148673 Log: gcc/ 2009-06-18 H.J. Lu PR target/40470 * config/i386/i386.h (CLASS_LIKELY_SPILLED_P): Add SSE_FIRST_REG. gcc/testsuite/ 2009-06-18 H.J. Lu PR target/40470 * gcc.dg/torture/pr40470-1.c: New. * gcc.dg/torture/pr40470-2.c: Likewise. * gcc.dg/torture/pr40470-3.c: Likewise. * gcc.dg/torture/pr40470-4.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr40470-1.c trunk/gcc/testsuite/gcc.dg/torture/pr40470-2.c trunk/gcc/testsuite/gcc.dg/torture/pr40470-3.c trunk/gcc/testsuite/gcc.dg/torture/pr40470-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40470
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-18 21:15 --- (In reply to comment #10) > Yes, I understood after a bit of dyslexia about it :-( > > Since the function result is a pointer, it is an ultimate component and, I > think, the deallocation of the allocatable components should not be attempted. I agree that no deallocation should happen. (Sorry for claiming so before.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug target/40470] unable to find a register to spill in class �SSE_FIRST_REG�
--- Comment #8 from hjl at gcc dot gnu dot org 2009-06-18 21:21 --- Subject: Bug 40470 Author: hjl Date: Thu Jun 18 21:21:42 2009 New Revision: 148675 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148675 Log: gcc/ 2009-06-18 H.J. Lu Backport from mainline: 2009-06-18 H.J. Lu PR target/40470 * config/i386/i386.h (CLASS_LIKELY_SPILLED_P): Add SSE_FIRST_REG. gcc/testsuite/ 2009-06-18 H.J. Lu Backport from mainline: 2009-06-18 H.J. Lu PR target/40470 * gcc.dg/torture/pr40470-1.c: New. * gcc.dg/torture/pr40470-2.c: Likewise. * gcc.dg/torture/pr40470-3.c: Likewise. * gcc.dg/torture/pr40470-4.c: Likewise. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr40470-1.c - copied unchanged from r148673, trunk/gcc/testsuite/gcc.dg/torture/pr40470-1.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr40470-2.c - copied unchanged from r148673, trunk/gcc/testsuite/gcc.dg/torture/pr40470-2.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr40470-3.c - copied unchanged from r148673, trunk/gcc/testsuite/gcc.dg/torture/pr40470-3.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr40470-4.c - copied unchanged from r148673, trunk/gcc/testsuite/gcc.dg/torture/pr40470-4.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/i386.h branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40470
[Bug target/40470] unable to find a register to spill in class �SSE_FIRST_REG�
--- Comment #9 from hjl at gcc dot gnu dot org 2009-06-18 21:23 --- Subject: Bug 40470 Author: hjl Date: Thu Jun 18 21:23:29 2009 New Revision: 148676 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148676 Log: gcc/ 2009-06-18 H.J. Lu Backport from mainline: 2009-06-18 H.J. Lu PR target/40470 * config/i386/i386.h (CLASS_LIKELY_SPILLED_P): Add SSE_FIRST_REG. gcc/testsuite/ 2009-06-18 H.J. Lu Backport from mainline: 2009-06-18 H.J. Lu PR target/40470 * gcc.dg/torture/pr40470-1.c: New. * gcc.dg/torture/pr40470-2.c: Likewise. * gcc.dg/torture/pr40470-3.c: Likewise. * gcc.dg/torture/pr40470-4.c: Likewise. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr40470-1.c - copied unchanged from r148675, trunk/gcc/testsuite/gcc.dg/torture/pr40470-1.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr40470-2.c - copied unchanged from r148675, trunk/gcc/testsuite/gcc.dg/torture/pr40470-2.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr40470-3.c - copied unchanged from r148675, trunk/gcc/testsuite/gcc.dg/torture/pr40470-3.c branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/torture/pr40470-4.c - copied unchanged from r148675, trunk/gcc/testsuite/gcc.dg/torture/pr40470-4.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.h branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40470
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #5 from heydowns at borg dot com 2009-06-18 21:26 ---
Was looking at modifying the spec to produce the desired results and contribute
patch, however ran into trouble trying to match options containing literal
colons (-std=iso9899:199409) in %{S:X} style spec.
Is there a way in the spec language to escape colons? I briefly scanned the
spec parsing code and nothing jumped out.
If not, is there some other way to match options containing colons (without
using greedy * matches, since the part after the colon is significant here...)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #6 from joseph at codesourcery dot com 2009-06-18 21:49 ---
Subject: Re: -std=c99 does not enable c99 mode in Solaris
C library
On Thu, 18 Jun 2009, heydowns at borg dot com wrote:
> Was looking at modifying the spec to produce the desired results and
> contribute
> patch, however ran into trouble trying to match options containing literal
> colons (-std=iso9899:199409) in %{S:X} style spec.
>
> Is there a way in the spec language to escape colons? I briefly scanned the
> spec parsing code and nothing jumped out.
>
> If not, is there some other way to match options containing colons (without
> using greedy * matches, since the part after the colon is significant here...)
You may well need to add a new feature to the specs parsing code to deal
with this.
I have some ideas about how option handling, multilib handling and some
aspects of specs should be redesigned, but this issue should not need any
redesign.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug testsuite/40488] [4.5 Regression] Revision 148642 caused extra failures
--- Comment #1 from rth at gcc dot gnu dot org 2009-06-18 23:28 --- Subject: Bug 40488 Author: rth Date: Thu Jun 18 23:27:40 2009 New Revision: 148685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148685 Log: PR 40488 * tree-pass.h (TDF_ASMNAME): New. * tree-dump.c (dump_options): Add asmname. * doc/invoke.texi: Document it. * tree-pretty-print.c (maybe_dump_asm_name): Merge into... (dump_decl_name): ...here. (dump_function_name): New flags arg; mind TDF_ASMNAME. (dump_generic_node): Update dump_function_name calls. (print_call_name): New flags arg; update all dump calls. * diagnostic.h (print_call_name): Update. * gimple-pretty-print.c (dump_gimple_call): Update. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.h trunk/gcc/doc/invoke.texi trunk/gcc/gimple-pretty-print.c trunk/gcc/tree-dump.c trunk/gcc/tree-pass.h trunk/gcc/tree-pretty-print.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40488
[Bug testsuite/40488] [4.5 Regression] Revision 148642 caused extra failures
--- Comment #2 from rth at gcc dot gnu dot org 2009-06-18 23:35 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40488
[Bug tree-optimization/40436] [4.5 regression] 0.5% code size regression caused by r147852
--- Comment #4 from ramana at gcc dot gnu dot org 2009-06-19 00:00 --- Confirmed that the problem exists. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-06-19 00:00:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
[Bug fortran/40440] Automatic deallocation component of DT function return value
--- Comment #12 from pault at gcc dot gnu dot org 2009-06-19 00:20 --- Adding at trans-expr.c:2740 && !(e->symtree && e->symtree->n.sym->attr.pointer) eliminates the problem in the reduced testcase and allows the original testcase to run correctly. This has not been regtested yet - even if it introduces regressions, it will be a question of getting the condition right. Notice that pointer variables need to be excluded from deallocation of allocatable components too. My tree is sourced from a more recent version of svn than is available on the system that I am using - hence the lack of a diff. It's mine :-) Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-06-15 13:09:45 |2009-06-19 00:20:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
[Bug c++/40490] New: failure to emit resolved inline virtual function definition or IMPORT on HP-UX with -O
The following input:
class A {
public:
A();
virtual void find() {}
};
static void foo(A &a)
{
a.find();
}
void bar()
{
A a;
foo(a);
}
when compiled with gcc-4.0.3, 4.0.4, 4.3.3 and 4.4.0 on HP-UX with -O
will produce assembly code that contains a call to find() but no
definition and no IMPORT:
$ gcc-4.4.0/bin/g++ -S -O repro.cc
$ grep 4find repro.s
bl _ZN1A4findEv,%r2
Contrast with A::A(), which has both a call and an IMPORT:
$ grep AC1 repro.s
bl _ZN1AC1Ev,%r2
.IMPORT _ZN1AC1Ev,CODE
The above input is approximately minimal; removing or changing any of
the features will make the problem disappear, typically by causing
find() to be completely inlined into the call site.
Interestingly, gcc-4.1.2 does not show a problem on this particular
input, although my recollection is it was showing the problem on a
larger variant. I do not know where along the minimization process
gcc-4.1.2 stopped reproducing.
The lack of an IMPORT despite no definition is particularly nasty,
because 'nm' simply reports it as an undefined symbol, but the HP-UX
linker refuses to link the result into an executable when presented
with another object file that contains the definition:
$ g++ -c -O repro.cc
$ g++ -c -O rest.cc # defines A::A() and main()
$ g++ repro.o rest.o
/usr/ccs/bin/ld: Unsatisfied symbols:
A::find()(first referenced in repro.o) (data)
collect2: ld returned 1 exit status
$ nm repro.o | grep 4find
U _ZN1A4findEv
$ nm rest.o | grep 4find
W _ZN1A4findEv
The above is with GNU 'as' 2.15 and 2.17 (same result). When using
the HP-UX assembler version "HP92453-03 UX.11.01.17 PA-RISC 2.0
Assembler" (which only accepts gcc-4.0.x output), it more helpfully
notices the missing IMPORT:
as: error 7403: undefined label - _ZN1A4findEv (7403)
Of course, I didn't discover the IMPORT issue until after some hours
of searching for an explanation to the mysterious linker complaint.
It would be nice if GNU 'as' would realize that it is creating a .o
file that cannot be linked.
For completeness, the HP-UX linker version is "92453-07 linker linker
ld B.11.63 071126".
The IMPORT anomaly is specific to HP-UX, but the failure to emit a
definition of an inline is not. On linux/x86_64 with gcc-4.0.3, for
example, repro.o again has a call but no definition, but is able to
link by using the definition from rest.o because there is no IMPORT
concept. I find it suspicious that the compiler would ever choose to
emit a direct call to a defined inline function without also including
that function's definition; but the C++ ODR guarantees the compiler it
will see the class definition again, including the method body, in the
translation unit containing the definition of A::A(), so the omission
is not by itself necessarily indicative of a bug.
It's worth noting that the presence of a direct call to find() means
the compiler figured out it is A::find() being called, despite that
method being virtual. I suspect the mechanism that does that may be
partly to blame. That's the reason for including "resolved" in this
bug's title.
--
Summary: failure to emit resolved inline virtual function
definition or IMPORT on HP-UX with -O
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smcpeak at coverity dot com
GCC build triplet: hppa2.0w-hp-hpux11.11
GCC host triplet: hppa2.0w-hp-hpux11.11
GCC target triplet: hppa2.0w-hp-hpux11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40490
[Bug libstdc++/13631] Problems in messages
--- Comment #29 from mrsam at courier-mta dot com 2009-06-19 00:47 --- Created an attachment (id=18022) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18022&action=view) Revised revised patch Here's a whack at actually keeping track of different message catalogs. It compiles, but I haven't tested it yet, I haven't yet figured out how to add a new testsuite to the source tree. Testing welcome. -- mrsam at courier-mta dot com changed: What|Removed |Added Attachment #18004|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13631
[Bug middle-end/40491] New: [4.5 Regression] Revision 148663 caused extra failures
On Linux/ia32, revision 148663: http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg00646.html caused: FAIL: gcc.dg/20080522-1.c (test for excess errors) FAIL: gcc.dg/20080528-1.c (test for excess errors) -- Summary: [4.5 Regression] Revision 148663 caused extra failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40491
