[Bug fortran/50375] gfortran must complain on NULL() ambiguity without MOLD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50375 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus 2011-09-14 07:17:48 UTC --- FIXED on the trunk (for 4.7). Thanks for the report!
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547 --- Comment #5 from Tobias Burnus 2011-09-14 07:19:03 UTC --- The patch fixes the issues of comment 0. However, one should go through the lengthy, convoluted thread at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/f014195ccf7b93e6/ to check whether it contains some still-unfixed issues.
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
--- Comment #4 from Andreas Krebbel 2011-09-14
07:20:14 UTC ---
I've looked into the 22_locale/money_get/get/char/13.cc failure.
The problem is a miscompilation of locale-inst.cc in libstdc++.
Source:
template
_InIter
money_get<_CharT, _InIter>::
do_get(iter_type __beg, iter_type __end, bool __intl, ios_base& __io,
ios_base::iostate& __err, long double& __units) const
{
string __str;
__beg = __intl ? _M_extract(__beg, __end, __io, __err, __str)
: _M_extract(__beg, __end, __io, __err, __str);
std::__convert_to_v(__str.c_str(), __units, __err, _S_get_c_locale());
return __beg;
}
The result of _M_extract is copied into the return ptr field of the
function. This assignment copies 12 bytes:
MEM[(struct iter_type *)&__beg] = MEM[(struct iter_type *)&D.23511];
expand_assignement expands this using store_field. However
store_bit_field_1 does not seem to handle BLKmode copies correctly for
byte big endian targets if the source cannot exactly be covered by
word mode operands. It calls itself recursively for the last chunk with:
store_bit_field_1 (str_rtx=0x3fff6528a38, bitsize=32, bitnum=64,
bitregion_start=0, bitregion_end=0,
fieldmode=DImode, value=0x3fff6528ab0, fallback_p=true)
with value being (subreg:DI (reg:TI 70) 8)
But copying 4 bytes from that value on a big endian target results in
a src value of (subreg:DI (reg:TI 70) 12) so the wrong word is being
copied here.
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 --- Comment #2 from Jan Hubicka 2011-09-14 07:38:03 UTC --- Created attachment 25267 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25267 somewhat reducted testcase.
[Bug other/50384] Copying a char array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50384
--- Comment #1 from Marc Glisse 2011-09-14
08:23:15 UTC ---
Don't know if it is the same problem, but gcc seems to have trouble optimizing
with structs:
//typedef struct A { unsigned char t; } A;
typedef unsigned char A;
extern A f(A,A);
A g(A x,A y){ return f(y,x); }
Gives a nice:
movzbl%dil, %eax
movzbl%sil, %edi
movl%eax, %esi
jmpf
whereas if I use the struct definition on the line above:
movl%edi, %eax
subq$8, %rsp
.cfi_def_cfa_offset 16
movl%esi, %edi
movl%eax, %esi
callf
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
Somehow gcc doesn't realize that the 2 codes are equivalent (at least that's
how I understand the ABI).
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #8 from Vittorio Zecca 2011-09-14 08:23:39 UTC --- gfortran 4.7.0 fixes this one. However, sometimes I get the following: /home/vitti/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951: symbol lookup error: /home/vitti/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951: undefined symbol: mpfr_get_z_exp Never got this one, I have mpfr-3.0.0-4 How can I fix it?
[Bug fortran/50392] New: SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Bug #: 50392 Summary: SIGSEGV in gfc_trans_label_assign Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25268 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25268 just compile it SIGSEGV in gfc_trans_label_assign
[Bug fortran/50393] New: free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 Bug #: 50393 Summary: free() invalid pointer in mio_expr Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: zec...@gmail.com Created attachment 25269 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25269 just compile it with MALLOC_CHECK_=1 free() invalid pointer in mio_expr
[Bug c++/48320] [C++0x][4.6/4.7 Regression] Template parameter packs cannot be expanded in default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48320 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dodji Seketeli 2011-09-14 08:40:15 UTC --- Fixed in gcc-4_6-branch and in trunk (4.7).
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #5 from Andreas Krebbel 2011-09-14 08:41:21 UTC --- Created attachment 25270 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25270 Experimental fix On S/390 all the failures disappear with that patch.
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #9 from Tobias Burnus 2011-09-14 08:50:04 UTC --- (In reply to comment #8) > x86_64-unknown-linux-gnu/4.7.0/f951: > symbol lookup error: > undefined symbol: mpfr_get_z_exp > > Never got this one, I have mpfr-3.0.0-4 See http://www.mpfr.org/mpfr-3.0.0/#changes and http://www.mpfr.org/mpfr-3.0.1/mpfr.html#Changed-Functions "mpfr_get_z_exp changed in MPFR 3.0 [...] this function has been renamed to mpfr_get_z_2exp in MPFR 3.0" and "mpfr_get_z_exp is still available via a macro in mpfr.h". Seemingly, you have a f951 which has been compiled with MPFR 2.x but you run it with MPFR 3. In that case, the macro does not help. gfortran calls this function for real-to-integer conversions, which seems to be the only use.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin 2011-09-14 09:11:27 UTC --- (In reply to comment #0) > Created attachment 25269 [details] > just compile it with MALLOC_CHECK_=1 > > free() invalid pointer in mio_expr Valgrind doesn't complain on FreeBSD. Did you manage to fix your mpfr issue?
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2011-09-14 09:46:41 UTC --- Confirmed on gfortran 4.4.6, 4.5.3, 4.6.1, and trunk (r178842). The backtrace is pr50392.f90:3.20: assign 1 to kf 1 Warning: Deleted feature: ASSIGN statement at (1) kf Program received signal SIGSEGV, Segmentation fault. gfc_trans_label_assign (code=) at ../../work/gcc/fortran/trans-stmt.c:107 107 len = GFC_DECL_STRING_LEN (se.expr); (gdb) bt #0 gfc_trans_label_assign (code=) at ../../work/gcc/fortran/trans-stmt.c:107 #1 0x0001000b4d48 in trans_code (code=, cond=) at ../../work/gcc/fortran/trans.c:1204 #2 0x0001000dbb64 in gfc_generate_function_code (ns=) at ../../work/gcc/fortran/trans-decl.c:5211 #3 0x000100072f5d in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4404 #4 0x0001000af786 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:250 #5 0x0001007b72bc in toplev_main (argc=2, argv=0x7fff5fbfdc08) at ../../work/gcc/toplev.c:548 #6 0x00011974 in start ()
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Ever Confirmed|0 |1
[Bug lto/50394] New: [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Bug #: 50394 Summary: [meta-bug] Issues with building libreoffice with LTO Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org This is tracking PR for libreoffice issues, similar to PR45375
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Depends on||50383, 50381 Ever Confirmed|0 |1 --- Comment #1 from Jan Hubicka 2011-09-14 09:55:19 UTC --- Currently libreoffice dies building svx at PR50383. Also there are couple of errors even with -fpermissive. Could someone look into that?
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #1 from Paolo Carlini 2011-09-14 10:09:11 UTC --- On it.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2011-09-14 10:33:35 UTC --- (In reply to comment #1) > > just compile it with MALLOC_CHECK_=1 > > free() invalid pointer in mio_expr > Valgrind doesn't complain on FreeBSD. No problems either on x86-64-linux (w/ MALLOC_CHECK_, MALLOC_PERTURB_ but also with valgrind). Given that the code is rather standard, it must be either a local problem or one of the nasty race-condition bugs, which only trigger very rarely.
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2011-09-14 10:42:55 UTC --- The code looks valid (Fortran 90) to me. Except that "kf" needs to be re-defined before returning from the function. >From Fortran 95's deleted section: "B.1.4 ASSIGN, assigned GO TO, and assigned FORMAT" "The definitions of the ASSIGN and assigned GO TO statements are: assign-stmt is ASSIGN label TO scalar-int-variable Constraint: The label shall be the statement label of a branch target statement or format-stmt that appears in the same scoping unit as the assign-stmt. Constraint: scalar-int-variable shall be named and of type default integer. [...] "Execution of an ASSIGN statement causes a statement label to be assigned to an integer variable. While defined with a statement label value, the integer variable may be referenced only in the context of an assigned GO TO statement or as a format specifier in an input/output statement. An integer variable defined with a statement label value may be redefined with a statement label value or an integer value."
[Bug testsuite/50322] [avr]: fail: gcc.dg/tree-ssa/ivopts-lt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50322 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Keywords|missed-optimization | Last reconfirmed||2011-09-14 Component|tree-optimization |testsuite CC||vries at gcc dot gnu.org AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from vries at gcc dot gnu.org 2011-09-14 11:01:25 UTC --- the testcase uses 'long int' and 'char*', and the transformation is done provided they are the same size. avr sizes int : 2 long int : 4 long long int: 8 char*: 2 Changing 'long int' to 'int' makes the testcase pass for avr. The testcase needs to be adapted.
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 --- Comment #3 from Jan Hubicka 2011-09-14 11:32:47 UTC --- Created attachment 25271 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25271 More reduced testcase
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383 Jan Hubicka changed: What|Removed |Added Attachment #25271|0 |1 is obsolete|| --- Comment #4 from Jan Hubicka 2011-09-14 11:53:29 UTC --- Created attachment 25272 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25272 reduced testcase again ;)
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #6 from Dominique d'Humieres 2011-09-14 12:42:06 UTC --- > Created attachment 25270 [details] > Experimental fix I'll test the patch on ppc-darwin9, but it will take some time on my slow machine. Meanwhile do you understand why the tests do not fail on powerpc64-unknown-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01230.html ) and why there are "only" 30 failures on darwin?
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #7 from Dominique d'Humieres 2011-09-14 13:31:15 UTC --- Janus, I am worried about your fix as it seems to break at least the original tests of pr41656 and pr41685: pr41656.f90:68.13: procedure, pass(a) :: s_scal => s_coo_scal 1 Error: Argument mismatch for the overriding procedure 's_scal' at (1): INTENT mismatch in argument 'a' pr41656.f90:67.13: procedure, pass(a) :: s_scals => s_coo_scals 1 Error: Argument mismatch for the overriding procedure 's_scals' at (1): INTENT mismatch in argument 'a' pr41656.f90:174.6: use s_base_mat_mod 1 Fatal Error: Can't open module file 's_base_mat_mod.mod' for reading at (1): No such file or directory Could you double check with Salvatore that it is the intended behavior?
[Bug lto/50383] ICE in lto_symtab_register_decl, at lto-symtab.c:148
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50383
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #5 from Markus Trippelsdorf
2011-09-14 13:32:17 UTC ---
More reduced:
% cat test.cpp
typedef long unsigned int size_t;
extern "C" {
typedef unsigned short sal_uInt16;
};
class Resource {
};
namespace com {
namespace sun {
namespace star {
namespace uno {
class BaseReference {
};
enum UnoReference_Query {
UNO_QUERY, UNO_REF_QUERY
};
template < class interface_type > class Reference:public BaseReference {
public:
inline static void *operator new (:: size_t nSize) {
}
inline Reference (const BaseReference & rRef, UnoReference_Query);
};
class Exception {
};
class XInterface {
};
}
}
}
}
class OutputDevice:public Resource {
};
class Window:public OutputDevice {
};
class SystemWindow:public Window {
};
class Dialog:public SystemWindow {
};
class ModalDialog:public Dialog {
};
class TabPage:public Window {
};
class SvListEntry {
};
class SvLBoxEntry:public SvListEntry {
};
namespace com {
namespace sun {
namespace star {
namespace beans {
class XPropertySet: public::com::sun::star::uno::XInterface {
};
}
namespace xforms {
class XFormsUIHelper1: public::com::sun::star::uno::XInterface {
};
class XSubmission;
}
}
}
}
namespace svxform {
struct ItemNode;
typedef::com::sun::star::uno::Reference
<::com::sun::star::xforms::XFormsUIHelper1> XFormsUIHelper1_ref;
typedef::com::sun::star::uno::Reference <::com::sun::star::beans::XPropertySet>
XPropertySet_ref;
typedef::com::sun::star::uno::Reference <::com::sun::star::xforms::XSubmission>
XSubmission_ref;
class XFormsPage: TabPage {
XFormsUIHelper1_ref m_xUIHelper;
bool DoToolBoxAction (sal_uInt16 _nToolBoxID);
SvLBoxEntry *AddEntry (const XPropertySet_ref & _rPropSet);
void EditEntry (const XPropertySet_ref & _rPropSet);
};
class AddSubmissionDialog: ModalDialog {
public:
AddSubmissionDialog (Window *pParent, ItemNode *_pNode, const
XFormsUIHelper1_ref & _rUIHelper);
XSubmission_ref &GetNewSubmission () const {
}
};
}
using namespace::com::sun::star::beans;
using namespace::com::sun::star::uno;
namespace css =::com::sun::star;
namespace svxform {
bool XFormsPage::DoToolBoxAction (sal_uInt16 _nToolBoxID)
{
switch (_nToolBoxID) {
case 12: {
{
AddSubmissionDialog aDlg (this, __null, m_xUIHelper);
{
try {
Reference xNewSubmission =
aDlg.GetNewSubmission ();
Reference < XPropertySet > xNewPropSet
(xNewSubmission, UNO_QUERY);
SvLBoxEntry *pEntry = AddEntry (xNewPropSet);
} catch (Exception &) {
}
}
}
}
}
}
SvLBoxEntry *XFormsPage::AddEntry (const Reference < XPropertySet > &_rEntry)
{
}
void XFormsPage::EditEntry (const Reference < XPropertySet > &_rEntry)
{
}
}
% g++ -o /dev/null -O0 -nostdlib -Wfatal-errors -fpreprocessed -fpermissive
-flto -w -r -fpermissive test.cpp
lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:148
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #9 from Salvatore Filippone 2011-09-14 13:46:00 UTC --- (In reply to comment #8) > > The test case in my original post is wrong in this respect > I mean: in the original post for pr41656.
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #8 from Salvatore Filippone 2011-09-14 13:45:13 UTC --- Duh! My bad: all versions of scal are supposed to update the A dummy argument, which should be INTENT(INOUT). The test case in my original post is wrong in this respect :( Salvatore
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #11 from janus at gcc dot gnu.org 2011-09-14 13:49:24 UTC --- Hi Dominique, > I am worried about your fix as it seems to break at least the original tests > of > pr41656 and pr41685: thanks for noticing. But, from a quick glance, I would say that you don't need to worry: When committing the INTENT check, I had to modify 'dynamic_dispatch_5' in the testsuite, which is just the test case for PR41656. I checked that it is indeed invalid. However, I would be even more relieved if Salvatore could tell us that his latest code still compiles with gfortran ... Cheers, Janus
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #10 from janus at gcc dot gnu.org 2011-09-14 13:49:04 UTC --- Hi Dominique, > I am worried about your fix as it seems to break at least the original tests > of > pr41656 and pr41685: thanks for noticing. But, from a quick glance, I would say that you don't need to worry: When committing the INTENT check, I had to modify 'dynamic_dispatch_5' in the testsuite, which is just the test case for PR41656. I checked that it is indeed invalid. However, I would be even more relieved if Salvatore could tell us that his latest code still compiles with gfortran ... Cheers, Janus
[Bug bootstrap/50395] New: Infinite loop when bootstrapping java
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50395 Bug #: 50395 Summary: Infinite loop when bootstrapping java Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org During java bootstrap the s390x-ibm-linux-gnu/32/libjava/.libs/lt-gcj-dbtool gets trapped in an endless loop after throwing an exception. It has been introduced between r176700 and r176730. Most revisions in between do not bootstrap due to compilation errors caused by the first bunch of dwarf2cfi patches (r176701 - r176704). Here are a few GDB backtraces from the endless loop: #0 0x75aca982 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #1 0x76877d4a in _Jv_Throw (value=0x75534648) at /build/gcc-head/libjava/exception.cc:118 #2 0x768b949e in java::lang::Class::initializeClass (this=0x77cbda48) at /build/gcc-head/libjava/java/lang/natClass.cc:808 #3 0x76868894 in _Jv_InitClass (klass=0x77cbda48) at /build/gcc-head/libjava/java/lang/Class.h:742 #4 _Jv_AllocObjectNoFinalizer (klass=0x77cbda48) at /build/gcc-head/libjava/prims.cc:586 #5 0x768dd77a in gnu.gcj.runtime.PersistentByteMap.init(gnu.gcj.runtime.PersistentByteMap, java.io.File, int, int)void (this=@75b16ee0, m=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:181 #6 0x768ddaba in gnu.gcj.runtime.PersistentByteMap.emptyPersistentByteMap(java.io.File, int, int)gnu.gcj.runtime.PersistentByteMap (name=@75530e90, capacity=32749, strtabSize=1047968) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:231 #7 0x00403aa4 in gnu.gcj.tools.gcj_dbtool.Main.main(java.lang.String[])void (s=@75558c00) at /build/gcc-head/libjava/gnu/gcj/tools/gcj_dbtool/Main.java:82 #0 0x76877b0e in base_of_encoded_value (encoding=1 '\001', context=0x0) at /build/gcc-head/libjava/.././libjava/../libgcc/unwind-pe.h:102 #1 0x76877f50 in read_encoded_value (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/.././libjava/../libgcc/unwind-pe.h:284 #2 __gcj_personality_v0 (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/exception.cc:373 #3 0x75aca988 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #4 0x76877d4a in _Jv_Throw (value=0x75534648) at /build/gcc-head/libjava/exception.cc:118 #5 0x768b949e in java::lang::Class::initializeClass (this=0x77cbda48) at /build/gcc-head/libjava/java/lang/natClass.cc:808 #6 0x76868894 in _Jv_InitClass (klass=0x77cbda48) at /build/gcc-head/libjava/java/lang/Class.h:742 #7 _Jv_AllocObjectNoFinalizer (klass=0x77cbda48) at /build/gcc-head/libjava/prims.cc:586 #8 0x768dd77a in gnu.gcj.runtime.PersistentByteMap.init(gnu.gcj.runtime.PersistentByteMap, java.io.File, int, int)void (this=@75b16ee0, m=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:181 #9 0x768ddaba in gnu.gcj.runtime.PersistentByteMap.emptyPersistentByteMap(java.io.File, int, int)gnu.gcj.runtime.PersistentByteMap (name=@75530e90, capacity=32749, strtabSize=1047968) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:231 #10 0x00403aa4 in gnu.gcj.tools.gcj_dbtool.Main.main(java.lang.String[])void (s=@75558c00) at /build/gcc-head/libjava/gnu/gcj/tools/gcj_dbtool/Main.java:82 #0 0x76878170 in read_encoded_value (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/.././libjava/../libgcc/unwind-pe.h:284 #1 get_ttype_entry (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/exception.cc:200 #2 __gcj_personality_v0 (version=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/exception.cc:438 #3 0x75aca988 in _Unwind_RaiseException () from /lib/libgcc_s.so.1 #4 0x76877d4a in _Jv_Throw (value=0x75534648) at /build/gcc-head/libjava/exception.cc:118 #5 0x768b949e in java::lang::Class::initializeClass (this=0x77cbda48) at /build/gcc-head/libjava/java/lang/natClass.cc:808 #6 0x76868894 in _Jv_InitClass (klass=0x77cbda48) at /build/gcc-head/libjava/java/lang/Class.h:742 #7 _Jv_AllocObjectNoFinalizer (klass=0x77cbda48) at /build/gcc-head/libjava/prims.cc:586 #8 0x768dd77a in gnu.gcj.runtime.PersistentByteMap.init(gnu.gcj.runtime.PersistentByteMap, java.io.File, int, int)void (this=@75b16ee0, m=Unhandled dwarf expression opcode 0xf3 ) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:181 #9 0x768ddaba in gnu.gcj.runtime.PersistentByteMap.emptyPersistentByteMap(java.io.File, int, int)gnu.gcj.runtime.PersistentByteMap (name=@75530e90, capacity=32749, strtabSize=1047968) at /build/gcc-head/libjava/gnu/gcj/runtime/PersistentByteMap.java:231 #10 0x00403aa4 in gnu.gcj.tools.gcj_dbtool.Main.main(java.lang.String[])void (s=@75558c00) at /build/gcc-head
[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176
--- Comment #7 from Igor Zamyatin 2011-09-14
14:30:35 UTC ---
In RTL everythin is vice-versa, additional instruction appears:
For the "bad" case couple instructions are responsible for cb load (asmcons
dump):
(insn 52 51 53 5 (set (reg:QI 83 [ D.2685 ])
(mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
(reg/v:SI 117 [ col ])) [0 MEM[base: inptr1_19, index:
col_90, offset: 0B]+0 S1 A8])) ../test_bad_4_6.c:42 66 {*movqi_internal}
(nil))
and later
(insn 62 61 122 5 (parallel [
(set (reg:SI 152 [ D.2685 ])
(zero_extend:SI (reg:QI 83 [ D.2685 ])))
(clobber (reg:CC 17 flags))
]) ../test_bad_4_6.c:47 123 {*zero_extendqisi2_movzbl_and}
(expr_list:REG_DEAD (reg:QI 83 [ D.2685 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
while in "good" case only one:
(insn 52 51 53 5 (parallel [
(set (reg/v:SI 84 [ cb ])
(zero_extend:SI (mem:QI (plus:SI (reg/v/f:SI 75 [ inptr1 ])
(reg/v:SI 119 [ col ])) [0 MEM[base: inptr1_19,
index: col_90, offset: 0B]+0 S1 A8])))
(clobber (reg:CC 17 flags))
]) ../test_good_4_6.c:42 123 {*zero_extendqisi2_movzbl_and}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
And life ranges in "bad" case became splitted:
a34(r152): [71..82]
a38(r83): [83..92]
And in "good" case only:
a34(r84): [71..90]
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #19 from vries at gcc dot gnu.org 2011-09-14 14:32:12 UTC --- Author: vries Date: Wed Sep 14 14:32:07 2011 New Revision: 178853 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178853 Log: 2011-09-14 Tom de Vries PR middle-end/50251 * explow.c (emit_stack_restore): Set crtl->need_drap if stack_restore is emitted. Modified: trunk/gcc/ChangeLog trunk/gcc/explow.c
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #21 from vries at gcc dot gnu.org 2011-09-14 14:37:46 UTC --- patch and test-case checked in.
[Bug middle-end/50251] [4.7 Regression] Revision 178353 caused many test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50251 --- Comment #20 from vries at gcc dot gnu.org 2011-09-14 14:33:40 UTC --- Author: vries Date: Wed Sep 14 14:33:35 2011 New Revision: 178854 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178854 Log: 2011-09-14 Tom de Vries PR middle-end/50251 * gcc.dg/pr50251.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr50251.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 Scott A. Colcord changed: What|Removed |Added CC||sacolcor at provide dot net --- Comment #8 from Scott A. Colcord 2011-09-14 14:59:01 UTC --- Now that has been ratified as part of the C++11 standard, shouldn't failure to support it be considered a bug? At the least, it seems like a WONTFIX status isn't appropriate, because (as I understand it) WONTFIX means that even if someone were to offer to do the work, there's no interest in accepting it into the tree.
[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47978 --- Comment #12 from Salvatore Filippone 2011-09-14 15:02:46 UTC --- (In reply to comment #11) > relieved if Salvatore could tell us that his > latest code still compiles with gfortran ... > > Cheers, > Janus Yes it does. No (new) worries here Salvatore
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #9 from Paolo Carlini 2011-09-14 15:09:45 UTC --- tr1::regex is definitely a wontfix. std::regex is a completely different matter, of course should be implemented, maybe you can help?!?
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #10 from Jonathan Wakely 2011-09-14 15:13:57 UTC --- It's a known issue that std::regex is incomplete, as documented in the libstdc++ manual. If it makes you feel better file a bug, but it isn't going to make any difference to anything. We know it's incomplete, we haven't forgotten, we aren't waiting until someone notices before working on it. As Paolo says, contributions would be far more helpful than a bug report.
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #11 from Jonathan Wakely 2011-09-14 15:26:23 UTC --- And for std::regex, what would be more useful than just "it's not fully implemented yet" would be listing what's missing, e.g. I disabled support for anchors because it was buggy, see PR 49870 (which you'll notice noone has closed as INVALID or WONTFIX)
[Bug libstdc++/43241] std::tr1::regex is not fully implemented yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43241 --- Comment #12 from Scott A. Colcord 2011-09-14 15:36:46 UTC --- As long as std::regex is still on the todo list, that resolves my concern. And I would love to be able to help; if you can give me a couple of extra hours in my day, I'll happily devote them to developing this feature. :-P
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf 2011-09-14 16:03:07 UTC --- Just successfully built libreoffice with todays gcc without LTO. I ran into three issues: 1) I use the following patch to include in gcc/gthr-posix.h. This gets rid of many trivial errors. diff --git a/gcc/gthr-posix.h b/gcc/gthr-posix.h index b1d499d..3c155d0 100644 --- a/gcc/gthr-posix.h +++ b/gcc/gthr-posix.h @@ -39,6 +39,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #include +#include #if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \ || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK)) Revision 176335 deleted this include and the authors insist that this is the right thing to do... 2) There is an error in ./oox/inc/oox/helper/refmap.hxx: ../../inc/oox/helper/refmap.hxx:182:86: error: no matching function for call to 'find(oox::RefMap, oox::xls::DefinedName>::key_type&)' Fixed by following the note given in the warning that proceeds the error: ../../inc/oox/helper/refmap.hxx:182:86: warning: 'find' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../inc/oox/helper/refmap.hxx:182:86: note: declarations in dependent base 'std::map, std::less, std::allocator > > >' are not found by unqualified lookup ../../inc/oox/helper/refmap.hxx:182:86: note: use 'this->find' instead 3) There were three identical errors in /sc/source/ui/view/dbfunc.cxx (complaining that GetViewData() cannot be called without an object). Fixed by putting a "this->" before GetViewData() in lines 434, 463 and 473.
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
--- Comment #3 from Tobias Burnus 2011-09-14
16:08:16 UTC ---
Patch:
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1264,9 +1265,7 @@ gfc_get_symbol_decl (gfc_symbol * sym)
TREE_USED (sym->backend_decl) = 1;
if (sym->attr.assign && GFC_DECL_ASSIGN (sym->backend_decl) == 0)
- {
- gfc_add_assign_aux_vars (sym);
- }
+ gfc_add_assign_aux_vars (sym);
if (sym->attr.dimension
&& DECL_LANG_SPECIFIC (sym->backend_decl)
@@ -1277,6 +1276,10 @@ gfc_get_symbol_decl (gfc_symbol * sym)
return sym->backend_decl;
}
+ if (sym->result == sym && sym->attr.assign
+ && GFC_DECL_ASSIGN (sym->backend_decl) == 0)
+gfc_add_assign_aux_vars (sym);
+
if (sym->backend_decl)
return sym->backend_decl;
[Bug target/50396] New: SSE division by zero generates incorrect code with optimizations enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50396 Bug #: 50396 Summary: SSE division by zero generates incorrect code with optimizations enabled Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: math...@gaunard.com Created attachment 25273 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25273 divide by zero example The attached C code, written using SSE intrinsics, prints -nan when no optimizations are used (as expected) and 0 otherwise. It seems constant folding of the divps instruction doesn't do the right thing. It works correctly when the first argument is non-zero though (including minus zero).
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 --- Comment #2 from paolo at gcc dot gnu.org 2011-09-14 16:20:12 UTC --- Author: paolo Date: Wed Sep 14 16:19:59 2011 New Revision: 178857 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178857 Log: /cp 2011-09-14 Paolo Carlini PR c++/50391 * pt.c (regenerate_decl_from_template): Don't pass an error_mark_node to build_exception_variant. /testsuite 2011-09-14 Paolo Carlini PR c++/50391 * g++.dg/cpp0x/noexcept15.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 --- Comment #3 from Paolo Carlini 2011-09-14 16:20:53 UTC --- Done.
[Bug c++/50391] [C++0x] ICE on invalid code, pair with incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50391 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini 2011-09-14 16:21:20 UTC --- .
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
--- Comment #4 from Tobias Burnus 2011-09-14
16:40:08 UTC ---
(In reply to comment #3)
> Patch:
I have accidentally submitted the patch before testing finished. It does not
work. The problem is that it does create the required declaration - but it does
not get used as one later calls gfc_get_fake_result_decl, which does not
propagate this information on.
That's fixed by applying additionally the following patch, which feels slightly
hackish.
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -2557,6 +2561,9 @@ gfc_get_fake_result_decl (gfc_symbol * sym, int
parent_flag)
else
current_fake_result_decl = build_tree_list (NULL, decl);
+ if (sym->attr.assign)
+DECL_LANG_SPECIFIC (decl) = DECL_LANG_SPECIFIC (sym->backend_decl);
+
return decl;
}
... maybe by moving the gfc_add_assign_aux_vars to gfc_get_fake_result_decl -
like below?
@@ -2501,6 +2501,10 @@ gfc_get_fake_result_decl (gfc_symbol * sym, int
parent_flag)
if (!sym)
return NULL_TREE;
+ if (sym->attr.assign
+ && GFC_DECL_ASSIGN (sym->backend_decl) == 0)
+gfc_add_assign_aux_vars (sym);
+
if (sym->ts.type == BT_CHARACTER)
{
if (sym->ts.u.cl->backend_decl == NULL_TREE)
[Bug fortran/50392] SIGSEGV in gfc_trans_label_assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org 2011-09-14 17:10:59 UTC --- (In reply to comment #4) > (In reply to comment #3) > > Patch: > > I have accidentally submitted the patch before testing finished. It does not > work. The problem is that it does create the required declaration - but it > does > not get used as one later calls gfc_get_fake_result_decl, which does not > propagate this information on. > > That's fixed by applying additionally the following patch, which feels > slightly > hackish. Just a FYI. The following code works with the current gfortran. function kf() result(j) assign 3 to j 3 continue j = 3 end
[Bug middle-end/50137] [4.7 Regression] ppc64/libstdc++-v3 is miscompiled on powerpc-apple-darwin9 since revision 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50137 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Dominique d'Humieres 2011-09-14 18:01:25 UTC --- This pr is fixed with the patch in http://gcc.gnu.org/bugzilla/attachment.cgi?id=25270 (pr50325 comment #5). Marking as a duplicate. *** This bug has been marked as a duplicate of bug 50325 ***
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Dominique d'Humieres changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #7 from Dominique d'Humieres 2011-09-14 18:01:25 UTC --- *** Bug 50137 has been marked as a duplicate of this bug. ***
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Ever Confirmed|0 |1 --- Comment #8 from Dominique d'Humieres 2011-09-14 18:03:03 UTC --- With the patch in comment #5 > Created attachment 25270 [details] > Experimental fix and after rebuilding libstdc++-v3 for both -m32 and -m64, the tests with -m64 gives ... Running target unix/-m64 ... === libstdc++ Summary === # of expected passes7234 # of unexpected failures2 # of expected failures46 # of unsupported tests732 So the patch fixes pr50137. I'll start a clean bootstrap and a full regtest tonight (allow for ~36h for the cycle).
[Bug other/49533] [4.7 regression] Revision 174989 (ipa-inline-transform.c) regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 Dmitry Gorbachev changed: What|Removed |Added CC||d.g.gorbachev at gmail dot ||com --- Comment #16 from Dmitry Gorbachev 2011-09-14 18:28:20 UTC --- *** Bug 50226 has been marked as a duplicate of this bug. ***
[Bug c++/50226] Wrong code with -O -fno-implicit-templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50226 Dmitry Gorbachev changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Dmitry Gorbachev 2011-09-14 18:28:20 UTC --- Fixed by r178809. *** This bug has been marked as a duplicate of bug 49533 ***
[Bug target/49826] [4.7 Regression] Symbols are not decorated with attribute stdcall and -mrtd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49826 --- Comment #1 from Dmitry Gorbachev 2011-09-14 19:35:41 UTC --- Created attachment 25274 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25274 patch
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 --- Comment #10 from Vittorio Zecca 2011-09-14 20:01:17 UTC --- gfortran 4.7.0 has been compiled with the old mpfr 2.4.2, I just downloaded it, this one will probably work. Anyway gfortran 4.7.0 does not give free() errors.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 --- Comment #3 from Vittorio Zecca 2011-09-14 20:03:44 UTC --- It seems to work now, no free() error messages. Maybe you can close the issue.
[Bug fortran/50378] MALLOC_CHECK_ glibc detects free() invalid pointer in compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50378 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #11 from kargl at gcc dot gnu.org 2011-09-14 20:13:17 UTC --- (In reply to comment #10) > gfortran 4.7.0 has been compiled with the old mpfr 2.4.2, I just downloaded > it, > this one will probably work. > Anyway gfortran 4.7.0 does not give free() errors. Thanks for the bug report and confirming that the issue is fixed.
[Bug fortran/50393] free() invalid pointer in mio_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50393 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||WORKSFORME --- Comment #4 from kargl at gcc dot gnu.org 2011-09-14 20:16:06 UTC --- (In reply to comment #3) > It seems to work now, no free() error messages. Maybe you can close the issue. Again, thanks for the bug report. This may also have been fixed by Mikael patch. I'm closing this with a WORKSFORME tag. FIXED might also apply.
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 --- Comment #22 from Ramana Radhakrishnan 2011-09-14 20:26:43 UTC --- On 14 Sep 2011, at 07:48, "ebotcazou at gcc dot gnu.org" wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 > > --- Comment #21 from Eric Botcazou 2011-09-14 > 06:48:01 UTC --- >> All callee saved registers should never changed after function call. Here fp >> has been changed is not because it is after a function call, it is because it >> is after the target of non local goto. I'm not familiar with the >> implementation >> of non local goto, but I guess there is some convention/protocol defines >> which >> registers may be changed after the target of a non local goto. > > That's not the problem. The problem is that the blockage isn't honored. By ? > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You reported the bug.
[Bug c++/50388] Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50388 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.1, 4.7.0 Resolution||WORKSFORME --- Comment #2 from Paolo Carlini 2011-09-14 20:55:12 UTC --- Indeed, this does *not* happen in mainline and 4_6-branch. And it's an ICE on *invalid*: at this point, realistically, will not be fixed in 4_5-branch.
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 --- Comment #1 from Paolo Carlini 2011-09-14 20:59:20 UTC --- Can you try reducing your testcase? 563 KB is definitely unmanageable.
[Bug c++/50276] [C++0x] Wrong "used uninitialized in this function" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50276 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 CC||jason at gcc dot gnu.org Summary|Wrong "used uninitialized |[C++0x] Wrong "used |in this function" warning |uninitialized in this |[C++0x] |function" warning Ever Confirmed|0 |1 Severity|minor |normal --- Comment #2 from Paolo Carlini 2011-09-14 21:03:48 UTC --- Note: -Wuninitialized required.
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 --- Comment #2 from Paolo Carlini 2011-09-14 21:11:02 UTC --- So, I guess we only need confirmation that your analysis is correct. Indeed, I can confirm that the patch, only one line thus not requiring a Copyright assignment, works for the testcase (however, I didn't fully regression test it yet). Jason, can you have a look? PS: Current Comeau accepts the snippet.
[Bug c++/50344] friend declaration confused by const qualifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50344 --- Comment #3 from Paolo Carlini 2011-09-14 21:34:35 UTC --- Passes the testsuite.
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 Andrea Arteaga changed: What|Removed |Added Attachment #25203|0 |1 is obsolete|| --- Comment #2 from Andrea Arteaga 2011-09-14 22:46:19 UTC --- Created attachment 25275 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25275 Not-preprocessed source As requested, I attach a minimal source code with some comments. There are no external dependencies, just gets #included. The compilation result is the same as already stated (segmentation fault during compilation).
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303 --- Comment #3 from Andrea Arteaga 2011-09-14 22:47:56 UTC --- I recently blogged about this issue: http://wp.me/pzWEm-9N.
[Bug c++/50303] [C++0x] Segfault with variadic template template parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50303
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-09-14
CC||jason at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #4 from Paolo Carlini 2011-09-14
23:11:11 UTC ---
Ah, ok, the below seems enough:
template
struct A1 {
};
template class... Actions>
void g2() {
g2();
}
int main()
{
g2();
}
[Bug middle-end/50397] New: openssl crash due to incorrect codegen when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397
Bug #: 50397
Summary: openssl crash due to incorrect codegen when using LTO
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net
When adding -flto and compiling openssl-1.0.0d with gcc-4.6.real (Ubuntu/Linaro
4.6.1-9ubuntu2) that comes with Ubuntu 11.10, the testsuite fails with a
segfault during the bignumber tests.
To reproduce:
1. untar openssl-1.0.0d
2. make this change in the Configure file on the "debian-amd64" line:
"debian-amd64", "gcc:-m64 -DL_ENDIAN -DTERMIO -O2 -flto -floop-block
-floop-flatten -floop-interchange -floop-strip-mine -Wa,--noexecstack -g -Wall
-DMD32_REG_T=int::-D_REENTRANT::-Wl,-flto=2 -ldl
-Wl,-Bsymbolic-functions:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::",
3. make, which will run the tests and fail.
4. for extra grins, run the specific suite under valgrind:
matt@matt-desktop:~/openssl-1.0.0d/test$ valgrind -q --trace-children=yes
../util/shlib_wrap.sh ./bntest
[...]
==12136== Process terminating with default action of signal 8 (SIGFPE)
==12136== Integer divide by zero at address 0x40359EA94
==12136==at 0x433C4D: BN_div (bn_div.c:342)
==12136==by 0x403B86: main (bntest.c:1951)
Floating point exception (core dumped)
PS: I filed this as 4.6.2, given the number of patches that Linaro has applied
to this 4.6.1 base version. If that's wrong, let me know.
I tried testing it on trunk, but that gets an ICE during compile (filing a
separate bug).
[Bug middle-end/50397] openssl crash due to incorrect codegen when using LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50397 --- Comment #1 from Matt Hargett 2011-09-15 00:37:43 UTC --- BTW, worth noting that this also happens with just -O1 as well.
[Bug middle-end/50398] New: ICE when compiling openssl-1.0.0d with graphite optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50398 Bug #: 50398 Summary: ICE when compiling openssl-1.0.0d with graphite optimizations Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@use.net Created attachment 25276 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25276 pre-processed source of the file that triggers the ICE During compile of openssl-1.0.0d using trunk r177733. matt@matt-desktop:~/openssl-1.0.0d/engines/ccgost$ /usr/lib/gcc-snapshot/bin/gcc -I../../include -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O2 -floop-flatten -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM -c gosthash.c gosthash.c: In function 'hash_step': gosthash.c:87:12: internal compiler error: in psct_dynamic_dim, at graphite-poly.h:659 The crash goes away with "-O1 -floop-flatten", or if I remove -floop-flatten. valgrind doesn't provide any output related to this issue. Pre-processed source attached.
[Bug c++/50399] New: [c++11] Lookup error w/ enums
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50399
Bug #: 50399
Summary: [c++11] Lookup error w/ enums
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blelb...@cct.lsu.edu
$ cat cxx11_enum_lookup_bug.cpp
namespace A {
namespace B {
void F() { }
}
namespace C {
enum B { };
void G() { B::F(); }
}
}
$ /usr/lib/gcc-snapshot/bin/g++ --version
g++ (Debian 20110816-1) 4.7.0 20110816 (experimental) [trunk revision 177785]
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /usr/lib/gcc-snapshot/bin/g++ cxx11_enum_lookup_bug.cpp -c
$ /usr/lib/gcc-snapshot/bin/g++ cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function 'void A::C::G()':
cxx11_enum_lookup_bug.cpp:13:12: error: 'F' is not a member of 'A::C::B'
$ g++-4.6 --version
g++-4.6 (Debian 4.6.1-8) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4.6 cxx11_enum_lookup_bug.cpp -c
$ g++-4.6 cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’:
cxx11_enum_lookup_bug.cpp:13:12: error: ‘F’ is not a member of ‘A::C::B’
$ g++-4.5 --version
g++-4.5 (Debian 4.5.3-8) 4.5.3
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4.5 cxx11_enum_lookup_bug.cpp -c
$ g++-4.5 cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’:
cxx11_enum_lookup_bug.cpp:13:12: error: ‘F’ is not a member of ‘A::C::B’
$ g++-4.4 --version
g++-4.4 (Debian 4.4.6-8) 4.4.6
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-4.4 cxx11_enum_lookup_bug.cpp -c
$ g++-4.4 cxx11_enum_lookup_bug.cpp -c -std=c++0x
cxx11_enum_lookup_bug.cpp: In function ‘void A::C::G()’:
cxx11_enum_lookup_bug.cpp:13: error: ‘F’ is not a member of ‘A::C::B’
